logo separator

[mkgmap-dev] Unable to search for Address - GPSMAP64s

From Gerd Petermann gpetermann_muenchen at hotmail.com on Thu Jul 23 18:43:21 BST 2020

Hi Andrew,

if you ever travel to a rather well mapped area like western Europe you will find the address data quite complete. In Canada there are only a few active mappers and some of them prefer to import Canvec data which IMHO often adds more problems than it solves, esp. when imports are done without the necessary checks for duplicated data or conflicts.

So, yes, OSM data in Canada is not great when it comes to addresses or other information like POI.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Andrew Morris <drew101 at shaw.ca>
Gesendet: Donnerstag, 23. Juli 2020 19:17
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Unable to search for Address - GPSMAP64s

So my latest attempt was as much as a success as I can hope for.  Here's
the magic I used:


mkdir work
( cd work ; \
   java -jar /opt/mkgmap/splitter.jar ../canada-latest.osm.pbf )


( cd work ; java -jar /opt/mkgmap/mkgmap.jar --route --index \
                  --gmapsupp --location-autofill=is_in,nearest \
                  --preserve-element-order --add-pois-to-areas \
                  --link-pois-to-ways --housenumbers \
                  --process-exits --process-destination \
                  --split-name-index \
                  --bounds=../bounds-latest.zip \
                  --precomp-sea=../sea-latest.zip \
                  --series-name='Canada OSM 2020' \
                  --family-name='Canada OSM 2020' \
                  --area-name='Canada OSM 2020' \
                  --description='Canada OpenStreetMap (2020)' \
                  -c template.args )

I may (or may not) update to use a unique mapname/mapid instead of the
default 63240001.  (see below)

I was able to find (as best as can be - see below) my test address.


Now here's the bigger problem.  I've had a GPS in my backpack since
2003.  I use it for hiking, kayaking, a little Geocaching and for
navigation when I'm in a place I don't know (it was an essential tool
when I was in Hawaii!)  Address information is ESSENTIAL for my GPS.

Now this isn't a mkgmap issue, but if I raise this to the OpenStreetMap
group I'm probably better off going out and yelling at the sky.  The
address information in OSM is horrible.

I pulled down 5 blocks around my test address direct from OSM (it's a
5-8 year old neighbourhood in Red Deer, Alberta Canada) and there were
*3* addresses entered in 5 square blocks.  This just isn't acceptable
data for navigational maps.  I'm comfortable driving around Edmonton,
Calgary, Vancouver and most of the lower mainland, but give me an
address in Regina or Winnipeg?  Panic.

For example, I know where 42 Timberstone Way is in Red Deer, do you?
The resulting map data gets me to Timberstone Way and well, most Alberta
roads are simple so any human should be able to figure it out from
there.  But that isn't a good assumption to make, as I have real life
experience that the same situation would end badly in Calgary, Vancouver
or Hawaii...

Can I select a point on the map and route to it?  Yes, and that works as
expected.  But if I have to pull out my phone and look up where that is
with Google maps, why wouldn't I just, I don't know, use Google maps on
my phone? (yes, there are signal/GPS/privacy issues...)

Without reasonable address information your project seems kind of
academic to me.  Can you convert OSM to Garmin map format?  Yes.  Are
they useful?  I have doubts.

Now this isn't something this project has done wrong.  Mkgmap/splitter
while complicated are doing their job as designed.  But someone needs to
yell at the OSM group for allowing incomplete street data to be entered.
  They need a policy that without addresses it isn't valid data.  It's
like getting a store catalogue without prices or a cookbook without
measurements - interesting but mostly useless.

I totally understand the data in the OSM isn't the mkgmap project's
responsibility.  But as a project that uses their data in probably the
most useful way the data can be used (map data being used in navigation
devices), I'm guessing someone has direct contact with someone in the
OSM group and can apply some influence.  I do feel this issue directly
effects the long term feasibility/reliability/usability of both projects.

I won't say I've wasted my time.  I've figured out how to build these
maps and I now have that well documented for possible future use.  I may
look again in a few years to see if the data has gotten better, but for
now I'm off to find the best price on Garmin City Navigator North America.

I'm sorry this reads a bit like a rant.  I'm at fault for not looking
closer at the data.  I made assumptions that have bit me on the ass and
I'll learn from that.

I guess I'm just disappointed after a lot of effort.

Thank you to Gerd, Ticker and everyone else who answered my slightly
confused calls for help during this process!  It is great to get better
than commercial support from an open source development group when you
could have just as easily said "RTFM".  It really does make the decision
to abandon this all the more difficult.


On 07/23/20 00:38, Gerd Petermann wrote:
> Hi Andrew,
>
> did you already try with the bounds.zip for planet?
> Which address(es) do you search? Do you try a single place or various?
> Some hints for a test plan:
> For testing you should use a single file as input. If this works it is very likely that the complete map for Canada also works. You can use JOSM to download a small area around your place and try that or you can pick a single *.osm.pbf file produced by splitter.
> Make sure that the addresses you are searching are well mapped in that input file.
>
> If you test with the device make sure to rename all other *.img files that you installed before to e.g. *.img_old to avoid conflicts with family-ids or map-ids.
> You may upload such a small gmapsupp.img to http://files.mkgmap.org.uk/ and I can check if it works on my Oregon.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Andrew Morris <drew101 at shaw.ca>
> Gesendet: Mittwoch, 22. Juli 2020 23:21
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Unable to search for Address - GPSMAP64s
>
> So after some digging (and testing is still ongoing) I *think* I may
> have figured out what is going on.  My use of the --country-abbr='CA'
> instead of --country-abbr='CAN' may have been marking the addresses as
> not Canadian and thus they weren't showing.  I've tried removing the
> option completely hoping mkgmap would pick it up from the metadata, but
> I don't think that worked.  I'm going to need to start doing a better
> test plan.  Right now I'm kind of spinning my wheels and I'm on like
> build 15.
>
> Also there (at least in my opinion) is a bug in the firmware where if a
> map is disabled it shouldn't use that map file for address information,
> but it does.
>
> I'll update as soon as I get some results.  Unfortunately this process
> is slow (around 40 minutes each try) and I get distracted with other
> things...
>
> Thank you for the suggestion on the -c template.args and geonames-file
> options.  I'll give that a try on my next run.
>
> On 07/20/20 06:35, Ticker Berkin wrote:
>> Hi Andrew
>>
>> When you say you can't find cities, do you get a good list of nearby
>> cities from the Find>Cities menu entry, and if you change this to
>> search-by-name, can you find all that you'd expect (ie non-basemap
>> ones).
>>
>> When using Find>Address, do you get a sensible Country or Region list
>> in the initial selection field, and have selected something, do you get
>>    a list of Cities in the City selection field, similarly for Street. On
>> my device I need to clear the house number field to get from this point
>> to the list of addresses that I can then select (because most of my
>> addresses don't have housenumbers)
>>
>> I see references to postal_code in your bounds processing. I don't
>> think you are going to get anything sensible to happen by default
>> relating to Canadian postcodes; I think Garmin ZipCode handling only
>> deals with numerics.
>>
>> Unrelated suggestions are:
>>
>>    Get the splitter to generate useful tile names with the
>>    --geonames-file=... option.
>>
>>    Use these by having -c template.args rather than *.osm.pbf
>>
>>    Have the global --description at the end, after the above.
>>
>>    Beware of --split-name-index.
>>
>>    --link-pois-to-ways is a good option.
>>
>>    --code-page=1252 if you need French names with accents.
>>
>> See {mkgmap-rel}/examples/sample.cfg
>>
>> Ticker
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


More information about the mkgmap-dev mailing list