Typo in default style, two suggestions and a question
Hi List! In the default style for points there is an amenity=butchers which is wrong. It should be amenity=butcher. In the same line the symbol is defined as 0x2e00 which seems to be non-existent (at least at my Garmin etrex Legend HCx). I would suggest to set it to 0x2e02 (grocery store) which leads into the following patch: -shop=butchers [0x2e00 resolution 20] +shop=butcher [0x2e02 resolution 20] First suggestion for additional style: -amenity=recycling [0x2f15 resolution 20] +amenity=recycling [0x2f15 resolution 20 default_name 'recycling'] which would not have any effect if the language is set to english but in german the symbol is shown as 'UnbekanntVersorgungsbetrieb' which is nonsens. Setting the name would also show 'Recycling' for german language which is better (I think). Second suggestion for additional style: +amenity=post_box { name 'post box (${operator})' | 'post box (${name})' } +amenity=post_box [0x640f resolution 21 default_name 'post box'] I found it nasty that I wasn't able to find post boxes with my garmin. Unfortunately I couldn't find an appropriate symbol for that. So I took the symbol for 'Post' and put a 'post box' as addition text. Opinions? And the question: Is there a way to set the info field of the tags? And if yes, how much data can this info field hold? Currently some address info seem to be added to the info field if set in the data. But e.g. for restaurants I'd like to know the opening_hours and for post boxes the collection_times... I would suggest to take the OSM info tag as content for the info field. This would give one the possibility to also put additional data via the style definition. Any other hint how this can be solved? Regards Andre
2009/4/7 Andre Hinrichs <andre.hinrichs@gmx.de>:
And the question:
Is there a way to set the info field of the tags? And if yes, how much data can this info field hold? Currently some address info seem to be added to the info field if set in the data. But e.g. for restaurants I'd like to know the opening_hours and for post boxes the collection_times... I would suggest to take the OSM info tag as content for the info field. This would give one the possibility to also put additional data via the style definition. Any other hint how this can be solved?
I have already posted that idea some time ago. Unfortunately no solution has been suggested yet. The opening hours would really help... Paul -- Don't take life too seriously; you will never get out of it alive. -- Elbert Hubbard
On Tue, Apr 07, 2009 at 04:55:32PM +0200, Andre Hinrichs wrote:
First suggestion for additional style:
-amenity=recycling [0x2f15 resolution 20] +amenity=recycling [0x2f15 resolution 20 default_name 'recycling']
which would not have any effect if the language is set to english but in german the symbol is shown as 'UnbekanntVersorgungsbetrieb' which is nonsens. Setting the name would also show 'Recycling' for german language which is better (I think).
Could this be addressed in a TYP file? As far as I understand, the TYP file would allow labels to be translated. I haven't made any experiments with TYP files yet. I'd be disturbed to find English text in my Finnish Edge 705 menus. (So disturbed that I might attempt to add operator= or name= to any nearby amenity=recycling nodes.) For amenity=recycling, I'd define separate custom symbols (and default names) for each kind of material, e.g., paper, glass, metal, ..., multi-material (paper,cardboard,metal,plastic_bags,clothes,batteries in a cluster of bins). An important question is whether custom symbols defined in the TYP file will appear somewhere in the Where To? menus. Ideally, there'd be a Recycling submenu in "Public services", with submenus "All categories", "Paper", "Metal", and so on.
Second suggestion for additional style:
+amenity=post_box { name 'post box (${operator})' | 'post box (${name})' } +amenity=post_box [0x640f resolution 21 default_name 'post box']
I found it nasty that I wasn't able to find post boxes with my garmin. Unfortunately I couldn't find an appropriate symbol for that. So I took the symbol for 'Post' and put a 'post box' as addition text. Opinions?
Again, I'd define this in a TYP file if possible. Could we have a default TYP file to go with the default style?
Is there a way to set the info field of the tags? And if yes, how much data can this info field hold? Currently some address info seem to be added to the info field if set in the data. But e.g. for restaurants I'd like to know the opening_hours and for post boxes the collection_times...
This could also be useful for amenity:recycling, displaying opening hours, fees, and the kinds of materials collected (recycling:*=yes). Marko
I created a new map with r991 and wanted to give some feedback: I used the zipped osm data from geofabrik.de for thuringia. java -Xmx1500M -jar splitter.jar --mapid=41000001 --maxnodes=1000000 thueringen.osm.bz2 java -Xmx1512M -jar mkgmap.jar --tdbfile --family-id=41 --family-name=OSM_Thueringen --series-name=OSM_Thueringen --description=OSM_routable_map --overview-mapname=41000000 --route --gmapsupp --latin1 --net 410000*.osm.gz Splitter produced only one tile with the maxnodes=1000000 setting. Generation was fine, no errors whatsoever. The map worked fine on both mapsource and my eTrex Legend HCx. Some things I noticed while testing on the etrex: - The address search field appears in the menu. Of course it doesn't find anything by now, but at least the menu is present already. - The road-crossings search field works, but the city name input field behaves slightly erratic. It displays a list of road names (alphabetically sorted) to choose from. But when I enter a letter, the list disappears. I have to type the full name of a city, which will make the (full) list reappear with the specific city selected. (Same behavior in the citys field of the address search menu) - Roundabouts give routing informations in the wrong direction. Maybe this can be fixed be adding country informations to the mkgmap options. I thought this was implemented by looking in the is_in tag now. - There are no road name pois to search for. I thought generation is default by now and the --add-road-name-pois is no longer needed? - The motorway exit menu works fine. Not tried searching though. - A lot of POIs are named e.g. UnnamedParking or UnnamedATM (These are translations from my german names). I don't know where the 'Unnamed' string comes from, but it would surely be better to ignore missing tags instead of printing 'unnamed'. - Some search menues contain a 'find by name' context menu, some don't. (Only the 'find nearest ...'). As the 'find nearest ...' menu is limited to a fixed number of entries it's not possible to search for pois far away. As a workaround I could of course use the unlimited 'find by name' in the 'all pois' menu. Can anybody confirm that those menues appear/don't appear with other (commercial) maps? - General routing works fine. Recalculation is fine for me, at least for going by car. As always: Thanks for the awesome work !
0> In article <20090408074750.2u0kt7ejkkc884g4@mail.binaervarianz.de>, 0> stefan <URL:mailto:stefan@binaervarianz.de> ("Stefan") wrote: Stefan> - Roundabouts give routing informations in the wrong Stefan> direction. Maybe this can be fixed be adding country Stefan> informations to the mkgmap options. I thought this was Stefan> implemented by looking in the is_in tag now. I too have a Legend HCx. I find that roundabout routing is fine[*] unless the source data are in error. If you have a specific example, we can check the OSM data for it (or you could easily do so yourself). [*] Actually, the default access rules (e.g. no pedestrians on motorway roundabouts) don't appear to be set - I'll submit a patch once the highway symbols code is in. Stefan> - A lot of POIs are named e.g. UnnamedParking or UnnamedATM Stefan> (These are translations from my german names). I don't know Stefan> where the 'Unnamed' string comes from, but it would surely be Stefan> better to ignore missing tags instead of printing 'unnamed'. In English, they are similar (but with a space after "Unnamed"). I think these things are specified in the TYP file. I'm of a mind to start investigating how TYP files are constructed - but it won't be for a week or so, due to other commitments. I have a suspicion, for example, that there's a code there to make metres the native altitude unit, obviating the need to convert OSM data to feet.
Zitat von Toby Speight <T.M.Speight.90@cantab.net>:
I too have a Legend HCx. I find that roundabout routing is fine[*] unless the source data are in error. If you have a specific example, we can check the OSM data for it (or you could easily do so yourself).
The two roundabouts I encountered were here http://openstreetmap.com/?lat=51.10147&lon=10.67444&zoom=17&layers=B000FTF and I could have sworn that there was another one here http://openstreetmap.com/?lat=51.100354&lon=10.627655&zoom=18&layers=B000FTF... but that last one magically disappeared. I will look at them myself this afternoon. But for now I have neither JOSM nor a browser with flash installed at hand. Just a wild guess: are your 'fine' roundabouts possibly somewhere in GB?
Stefan> - A lot of POIs are named e.g. UnnamedParking or UnnamedATM Stefan> (These are translations from my german names). I don't know Stefan> where the 'Unnamed' string comes from, but it would surely be Stefan> better to ignore missing tags instead of printing 'unnamed'.
In English, they are similar (but with a space after "Unnamed"). I think these things are specified in the TYP file. I'm of a mind to start investigating how TYP files are constructed - but it won't be for a week or so, due to other commitments. I have a suspicion, for example, that there's a code there to make metres the native altitude unit, obviating the need to convert OSM data to feet.
It's without a space here. The 'have to start looking at the style files' part goes unchanged for me too. regards Stefan
On Wed, Apr 8, 2009 at 1:41 PM, <stefan@binaervarianz.de> wrote:
The two roundabouts I encountered were here [...]
I will look at them myself this afternoon. But for now I have neither JOSM nor a browser with flash installed at hand.
Just a wild guess: are your 'fine' roundabouts possibly somewhere in GB?
I can at least confirm that the roundabouts work correctly in Germany. I did have to correct several roundabouts in my area which were drawn in the incorrect direction. I would imagine that this is almost certainly the case in the cases you have found. (I also use the frig-roundabouts option, but I'm not sure if that is still necessary.) At the moment, the majority of routing problems which I encounter can be traced back to incorrect OSM data. Cheers.
never had an issue with roundabouts. routing and display work fine. And I am not in UK On 8 Apr 2009, at 4:41 , stefan@binaervarianz.de wrote:
Zitat von Toby Speight <T.M.Speight.90@cantab.net>:
I too have a Legend HCx. I find that roundabout routing is fine[*] unless the source data are in error. If you have a specific example, we can check the OSM data for it (or you could easily do so yourself).
The two roundabouts I encountered were here
http://openstreetmap.com/?lat=51.10147&lon=10.67444&zoom=17&layers=B000FTF
and I could have sworn that there was another one here
http://openstreetmap.com/?lat=51.100354&lon=10.627655&zoom=18&layers=B000FTF...
but that last one magically disappeared.
I will look at them myself this afternoon. But for now I have neither JOSM nor a browser with flash installed at hand.
Just a wild guess: are your 'fine' roundabouts possibly somewhere in GB?
Stefan> - A lot of POIs are named e.g. UnnamedParking or UnnamedATM Stefan> (These are translations from my german names). I don't know Stefan> where the 'Unnamed' string comes from, but it would surely be Stefan> better to ignore missing tags instead of printing 'unnamed'.
In English, they are similar (but with a space after "Unnamed"). I think these things are specified in the TYP file. I'm of a mind to start investigating how TYP files are constructed - but it won't be for a week or so, due to other commitments. I have a suspicion, for example, that there's a code there to make metres the native altitude unit, obviating the need to convert OSM data to feet.
It's without a space here. The 'have to start looking at the style files' part goes unchanged for me too.
regards
Stefan
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
0> In article <20090408134138.m4boy3jgv4g008kc@mail.binaervarianz.de>, 0> stefan <URL:mailto:stefan@binaervarianz.de> ("Stefan") wrote: Stefan> Just a wild guess: are your 'fine' roundabouts possibly Stefan> somewhere in GB? Yes - but I've found (and fixed) several that were drawn the wrong way. They can go unnoticed for a long time, as I think we're the pioneers in using OSM for routing! Perhaps your problematic ones were similarly found and fixed - how up-to-date is your input data?
Toby Speight wrote:
0> In article <20090408134138.m4boy3jgv4g008kc@mail.binaervarianz.de>, 0> stefan <URL:mailto:stefan@binaervarianz.de> ("Stefan") wrote:
Stefan> Just a wild guess: are your 'fine' roundabouts possibly Stefan> somewhere in GB?
Yes - but I've found (and fixed) several that were drawn the wrong way. They can go unnoticed for a long time, as I think we're the pioneers in using OSM for routing!
Garmin maps are without a doubt one of the nicest uses of OSM data but they aren't the pioneers of OSM routing. Have a look at OpenRouteService.org or Yournavigation.org as well as Navit and Gosmore among others. Those are available for over a year using OSM data for routing and are quite functional. I've received numerous mails from users of yournavigation.org stating that they use it extensively for testing and debugging their roadnetworks.
Perhaps your problematic ones were similarly found and fixed - how up-to-date is your input data? _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
0> In article <49DCF489.4010405@na1400.info>, 0> Lambertus <URL:mailto:osm@na1400.info> ("osm") wrote: osm> Garmin maps are without a doubt one of the nicest uses of OSM osm> data but they aren't the pioneers of OSM routing. Have a look at osm> OpenRouteService.org or Yournavigation.org as well as Navit and osm> Gosmore among others. Those are available for over a year using osm> OSM data for routing and are quite functional. I sit corrected - thanks for the information!
Stefan> Just a wild guess: are your 'fine' roundabouts possibly Stefan> somewhere in GB?
Yes - but I've found (and fixed) several that were drawn the wrong way. They can go unnoticed for a long time, as I think we're the pioneers in using OSM for routing!
Perhaps your problematic ones were similarly found and fixed - how up-to-date is your input data? _________________________
My input data was from April the 4th, somewhat about 1pm if I remember correctly. I just checked he roundabout with josm. The direction and the tags seem fine by now. I can' check the last modification date from within josm though. I think mkgmap routing is quite good if most of the errors originate from bad osm data. I will try the road-name-pios tomorrow and give feedback for this as well. The entrys in the exit-menu are from the basemap, as stated some mails before. Some additional information: the crossings menu worked when entering two streets and a city, but the street name list was not filtered / cut down to he streets actually in that city. Also when entering the second street name, the list is not filtered / cut down to the streets crossing the first street in that city. I don't know if any of these two behaviors are supposed to be different than that. (I don't own even one commercial map. I fully believed in mkgmap to bring OSM maps to the Garmin device when buying it.) As some others posted earlier: I too desperately want to add to the mkgmap development, but I just can't find the time to do so. I really do need o look into the java and the style-file code soon. regards Stefan
Hi Stefan, Thanks for the feedback.
I created a new map with r991 and wanted to give some feedback:
I used the zipped osm data from geofabrik.de for thuringia.
java -Xmx1500M -jar splitter.jar --mapid=41000001 --maxnodes=1000000 thueringen.osm.bz2
java -Xmx1512M -jar mkgmap.jar --tdbfile --family-id=41 --family-name=OSM_Thueringen --series-name=OSM_Thueringen --description=OSM_routable_map --overview-mapname=41000000 --route --gmapsupp --latin1 --net 410000*.osm.gz
Splitter produced only one tile with the maxnodes=1000000 setting. Generation was fine, no errors whatsoever. The map worked fine on both mapsource and my eTrex Legend HCx.
Some things I noticed while testing on the etrex:
- The address search field appears in the menu. Of course it doesn't find anything by now, but at least the menu is present already.
It does work with some known limitations. 1 - you need to enter a number or at least make the field blank. Otherwise, no addresses will be shown. 2 - the incremental search for city names does not work (you mention this below). 3 - incremental search doesn't work for road names consisting of only digits
- The road-crossings search field works, but the city name input field behaves slightly erratic. It displays a list of road names (alphabetically sorted) to choose from. But when I enter a letter, the list disappears. I have to type the full name of a city, which will make the (full) list reappear with the specific city selected. (Same behavior in the citys field of the address search menu)
Yes, this is known weirdness.
- Roundabouts give routing informations in the wrong direction. Maybe this can be fixed be adding country informations to the mkgmap options. I thought this was implemented by looking in the is_in tag now.
There has recently been discussed a fix for roundabout direction but that has not been evaluated yet in mkgmap.
- There are no road name pois to search for. I thought generation is default by now and the --add-road-name-pois is no longer needed?
No, the option is still needed and it is called --road-name-pois.
- The motorway exit menu works fine. Not tried searching though.
There's known weirdness in that as well because the gps will find exits in the basemap in preference to exits in the osm map.
- A lot of POIs are named e.g. UnnamedParking or UnnamedATM (These are translations from my german names). I don't know where the 'Unnamed' string comes from, but it would surely be better to ignore missing tags instead of printing 'unnamed'.
Don't know anything about that feature.
- Some search menues contain a 'find by name' context menu, some don't. (Only the 'find nearest ...'). As the 'find nearest ...' menu is limited to a fixed number of entries it's not possible to search for pois far away. As a workaround I could of course use the unlimited 'find by name' in the 'all pois' menu. Can anybody confirm that those menues appear/don't appear with other (commercial) maps?
- General routing works fine. Recalculation is fine for me, at least for going by car.
Good. Cheers, Mark
<stefan@binaervarianz.de> wrote:
- A lot of POIs are named e.g. UnnamedParking or UnnamedATM (These are translations from my german names). I don't know where the 'Unnamed' string comes from, but it would surely be better to ignore missing tags instead of printing 'unnamed'.
Stefan, you're probably aware of this, but in case someone needs a workaround... The Unnamed text is due to the default style. Adding a second point definition in the style file for Parking, ATM, whatever with some default text should prevent that, e.g.: amenity=fuel { name '${name}' | '' } amenity=fuel [0x2f01 resolution 19] Detailed information on styles and rules: http://wiki.openstreetmap.org/wiki/Mkgmap/help/Custom_styles http://wiki.openstreetmap.org/wiki/Mkgmap/help/style_rules Cheers, Chris
participants (11)
-
Andre Hinrichs -
Apollinaris Schoell -
Clinton Gladstone -
Lambertus -
leprof06＠yahoo.de -
Mark Burton -
Marko Mäkelä -
Paul Ortyl -
Stefan Aschenbach -
stefan＠binaervarianz.de
-
Toby Speight