Hi, I have tested the latest version of patch from Bernhard Heibler. I can see, that as far as the data is correct, the patch works fine with my etrex and should be merged to the trunk possibly soon. I do not know what to think about --location-autofill option. The missing data should be corrected at the source and not heuristicly patched in mkgmap. For this purpose a tool for listing POIs with incomplete addresses could be created. I would like to have the default behaviour of --pois-addresses flipped. I mean add the addresses wherever the data is available and allow the user strip the address information with --no-poi-adresses for creating smaller maps or maps targeted to devices, which have no use for address/phone information. One feature, which has already been mentioned last week are POIs for buildings. It is really a shame, that the better mapped parts of cities get stripped of all restaurants/hotels/supermarkets/... which are already existing on the map as buildings/polygons. Even if solutions in submitted patches are not ideal from the performance point of view, please create the users an option for creating complete map, at the cost of performance. Has anybody an idea how to cram into the POI information shown on the Garmin such things like opening_hours? Thanks for the great work on the conversion tool :) Paul -- Don't take life too seriously; you will never get out of it alive. -- Elbert Hubbard
On Wed, Feb 25, 2009 at 10:34:17PM +0100, Paul Ortyl wrote:
Hi,
I have tested the latest version of patch from Bernhard Heibler. I can see, that as far as the data is correct, the patch works fine with my etrex and should be merged to the trunk possibly soon. I do not know what to think about --location-autofill option. The missing data should be corrected at the source and not heuristicly patched in mkgmap. For this purpose a tool for listing POIs with incomplete addresses could be created. I would like to have the default behaviour of --pois-addresses flipped. I mean add the addresses
I second this - Make pois-addresses the default - remove heuristics until explicitly asked for and remove the "Fix My Address" fill string if there is nothing.
wherever the data is available and allow the user strip the address information with --no-poi-adresses for creating smaller maps or maps targeted to devices, which have no use for address/phone information. One feature, which has already been mentioned last week are POIs for buildings. It is really a shame, that the better mapped parts of cities get stripped of all restaurants/hotels/supermarkets/... which are already existing on the map as buildings/polygons. Even if solutions in submitted patches are not ideal from the performance point of view, please create the users an option for creating complete map, at the cost of performance.
Has anybody an idea how to cram into the POI information shown on the Garmin such things like opening_hours?
I guess its just a string presented to the user isnt it? Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin
Hi Guys, thanks for testing my stuff.
Ah - and another one - i get an entry for a Junk Food shop which has no addr: tags - It becomes "33330, 33332, 33334, 33335 Guetersloh" which is a list of postcodes in this city ... (And a correctly escaped ü) Yes this is indeed a bug. I should just ignore the postcode if there is a list.
I have tested the latest version of patch from Bernhard Heibler. I can see, that as far as the data is correct, the patch works fine with my etrex and should be merged to the trunk possibly soon. I do not know what to think about --location-autofill option. The missing data should be corrected at the source and not heuristicly patched in mkgmap. For this purpose a tool for listing POIs with incomplete addresses could be created. I would like to have the default behaviour of --pois-addresses flipped. I mean add the addresses
I second this - Make pois-addresses the default - remove heuristics until explicitly asked for and remove the "Fix My Address" fill string if there is nothing.
I also don't like the auto filling that much. Problem is that with the current osm data most location will end up in the default country / region since is_in tagging is rare for hamlets in Germany. This will make it difficult to distinguish between hamlets with same name in the city list. And in most other countries situation is even worse. I don't have a problem to disable the heuristic by default as long as there is a switch to enable it ... What should we do with the Road POI's ? I think disabling heuristic for them makes no sense since we need the city name to make them more unique. I experimented a little bit with ZIP data provided by geonames.org. This seams to help to improve the quality of the heuristic in non opengeodb countries. But this datasource also provides points and no polygons so it will be still guessing. I also looked a little bit in using administrative boundary data for the region naming but I'm not sure if the data sources are good enough ... I hope I could provide a patch with your suggestions on the weekend ... Thanks Berni.
On Thu, Feb 26, 2009 at 08:07:11PM +0100, Bernhard Heibler wrote:
I also don't like the auto filling that much. Problem is that with the current osm data most location will end up in the default country / region since is_in tagging is rare for hamlets in Germany. This will make it difficult to distinguish between hamlets with same name in the city list. And in most other countries situation is even worse. I don't have a problem to disable the heuristic by default as long as there is a switch to enable it ...
I made a slippy map overlay (.de only) for is_in which do not fit into the complete hierarchie - http://autobug.osm.rfc822.org - zoom in a little to let the icons pop up ... Together with the OSMXAPI link on the left one can download the place nodes in view and edit them quite quickly with JOSM. So there are quick tools to solve the is_in hierarchy problems ... Here is some html/csv/text output: http://autobug.osm.lab.rfc822.org/lists/ for all places in Germany. I fixed most of the broken is_in in NRW but did not fix all missing/empty is_in ... But once there is a real need and people see use for it i guess it'll be fixed quickly ... But there are more problems lurking - Sometimes the County (Kreis) has the same name as a City (Kreis Gütersloh -> Gütersloh). This bug was introduced by the geonames import which imported 2 nodes with different place type but same name. I corrected the node names too so Gutersloh with place=county became "Kreis Gütersloh" to be different to the City Gütersloh.
I experimented a little bit with ZIP data provided by geonames.org. This seams to help to improve the quality of the heuristic in non opengeodb countries. But this datasource also provides points and no polygons so it will be still guessing. I also looked a little bit in using administrative boundary data for the region naming but I'm not sure if the data sources are good enough ...
They arent existing most of the time ...
I hope I could provide a patch with your suggestions on the weekend ...
Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin
participants (3)
-
Bernhard Heibler -
Florian Lohoff -
Paul Ortyl