logo separator

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

From Andrew Morris drew101 at shaw.ca on Thu Jul 23 18:17:52 BST 2020

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
>


More information about the mkgmap-dev mailing list