[mkgmap-dev] a few points
hello,
i've been playing with mkgmap and etrex legend a little bit and these
are my findings:
examples/styles/default/point:
tourism=information {name '${name} - ${description} (${operator})'..
[0x2f0c resolution 20]
- this is most likely not right as 2f0c is
auto-services|rest-area-tourist-info|Restroom (and also renders as
such in garmin). it could be that tourism=information couples with
information=board (there's no building). hence you cannot assume that
restroom are always present.
amenity=place_of_worship [0x2c0b resolution 21]
- this is probably correct with newer garmins but in etrex legend it
renders as an attraction, probably better to replace with
0x64|0x04|manmade-places|church|Church
garmin_feature_list.csv:
trial - trail
i generated a map containing all possible types of point. there are
quite a few that are displayed in garmin but not included in
garmin_feature_list.csv. are you interested in listing them?
cheers,
jose
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] 0x10 for residential in default style
Hello all, At the moment, I’m merging my own custom style with the default, and I’m wondering about the use of code 0x10 for landuse=residential in the polygons file. Is 0x10 a standard Garmin code for residential areas? If not, isn’t 0x01/0x02/0x03 a better choice (0x03 is already in use for place=village)? BTW: I hope to be able to switch completely to the default style and then fit my TYP file to that. When I’m done with that, is there any interest for that TYP file? Regards, J-.___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] a few points
On Mon, Feb 07, 2011 at 07:22:11PM +0100, Jozef Riha wrote:
examples/styles/default/point:
tourism=information {name '${name} - ${description} (${operator})'..
[0x2f0c resolution 20]
- this is most likely not right as 2f0c is
auto-services|rest-area-tourist-info|Restroom (and also renders as such
in garmin).
We already have a symbol for amenity=toilet, 0x4e00, which does not show
up (and IMO does not need to show up) in the Where To? menu. Yes, the
0x2f0c displays as a toilet symbol when not using a TYP file, but in the
Edge 705, the Where To? menu entry is in Auto services, called Rest
Area/Tourist Info.
it could be that tourism=information couples with information=board
(there's no building). hence you cannot assume that restroom are always
present.
Correct. We are deliberately repurposing the 0x2f0c a little. A similar
error is with amenity=recycling. The Garmin symbol (utility) seems to
be the opposite of recycling, because in German it says Versorgung
(supply) instead of Entsorgung (disposal).
amenity=place_of_worship [0x2c0b resolution 21]
- this is probably correct with newer garmins but in etrex legend it
renders as an attraction, probably better to replace with
0x64|0x04|manmade-places|church|Church
Does the 0x6404 show up in the Where To? menu? The 0x2c0b does, and the
Finnish menu item in the Edge 705 means exactly place of worship. One
might want to navigate to the nearest church, e.g., as a tourist. The
Edge 705 is quite old already. Is the etrex legend still available for
sale?
garmin_feature_list.csv:
trial - trail
i generated a map containing all possible types of point. there are
quite a few that are displayed in garmin but not included in
garmin_feature_list.csv. are you interested in listing them?
Yes. Please post a patch.
It could be nice to list the Where To? menu items too, as in
http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types
Best regards,
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 0x10 for residential in default style
On Mon, Feb 07, 2011 at 09:45:03PM +0100, Jeroen Muris wrote: At the moment, I'm merging my own custom style with the default, and I'm wondering about the use of code 0x10 for landuse=residential in the polygons file. Is 0x10 a standard Garmin code for residential areas? It is not. I just made it up, because it seemed to render fine in my Edge 705. If not, isn't 0x01/0x02/0x03 a better choice (0x03 is already in use for place=village)? Could be. I guess that we should revise the polygon rules very soon. Do you agree with my idea that the landuse=residential and building=* polygons should be mutually exclusive? That is, show only the landuse=residential on higher zoom levels and only the buildings on lower zoom levels? BTW: I hope to be able to switch completely to the default style and then fit my TYP file to that. When I'm done with that, is there any interest for that TYP file? Yes. We could have multiple TYP files for the default style. Minko's Mapnik.TYP can be good for newer devices, while cferrero and I seem to prefer simpler non-spaghetti layout that works on older devices. I would prefer to have an open source TYP file generator or editor, so that changes to the TYP file could be tracked. But I guess we can live with binary-only TYP files, if there is no other choice. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 0x10 for residential in default style
Thank you for the quick response. For now I'll keep using my own 0x01 for landuse=residential. If the polygons styling needs work I'm willing to help. Just let me know what I can do. Switching from landuse=residential to building=* may be a nice solution (I did not know it is possible), but I'm not sure what the results are when one of those is missing in OSM. I'm afraid my TYP file is for newer models too, I made it for my own Oregon. Regards, J-. -Oorspronkelijk bericht- From: MarkoMäkelä Sent: Monday, February 07, 2011 10:08 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] 0x10 for residential in default style On Mon, Feb 07, 2011 at 09:45:03PM +0100, Jeroen Muris wrote: At the moment, I'm merging my own custom style with the default, and I'm wondering about the use of code 0x10 for landuse=residential in the polygons file. Is 0x10 a standard Garmin code for residential areas? It is not. I just made it up, because it seemed to render fine in my Edge 705. If not, isn't 0x01/0x02/0x03 a better choice (0x03 is already in use for place=village)? Could be. I guess that we should revise the polygon rules very soon. Do you agree with my idea that the landuse=residential and building=* polygons should be mutually exclusive? That is, show only the landuse=residential on higher zoom levels and only the buildings on lower zoom levels? BTW: I hope to be able to switch completely to the default style and then fit my TYP file to that. When I'm done with that, is there any interest for that TYP file? Yes. We could have multiple TYP files for the default style. Minko's Mapnik.TYP can be good for newer devices, while cferrero and I seem to prefer simpler non-spaghetti layout that works on older devices. I would prefer to have an open source TYP file generator or editor, so that changes to the TYP file could be tracked. But I guess we can live with binary-only TYP files, if there is no other choice. Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] 0x10 for residential in default style
On Mon, Feb 07, 2011 at 10:29:12PM +0100, Jeroen Muris wrote: If the polygons styling needs work I'm willing to help. Just let me know what I can do. Basically, suggest some changes, preferrably by sending patches. Switching from landuse=residential to building=* may be a nice solution (I did not know it is possible), but I'm not sure what the results are when one of those is missing in OSM. landuse=residential [0x10 resolution 23-18] building=* | man_made=* | amenity=* | tourism=* [0x13 resolution 24] When there is no building=*, you would see nothing at resolution 24. When there is no landuse=residential, you would see nothing at resolutions 18 to 23. The 18 could be too high, BTW. I would like the map to render fast at wide zooms and be small in size. I'm afraid my TYP file is for newer models too, I made it for my own Oregon. Do you know this problem? Does your TYP file have extra border lines around lines (other than motorways)? http://cferrero.net/maps/img/spag4.bmp http://cferrero.net/maps/img/nospag.bmp Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] splitter and long way-segments
Hi everyone I've a problem with ways with long segments (e.g. boarders or ferry-lines) and splitter. These ways gets broken, because the nodes are to far away from splitoffset. I've made a screenshot [1] for explanation. Increasing the splitter-offset wont be a good idea, because tiles will become to big. Also I wont add additional nodes in osm-data, because this only will solve the problem only for one map. Are there any other opportunities for fixing this problem and keep routing on ferry-lines alife? Henning [1] http://www.aighes.de/data/example.png ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] splitter and long way-segments
Henning, Did you try a higher overlap setting? Maybe --overlap=6000 ? --overlap Nodes/ways/rels that fall outside an area will still be included if they are within this many map units. Default is 2000 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] patch for polygons file
Marko, I'll have a look at the polygons style file. For know I'll send the results of merging the default style with my own (polygons-1829-JM.patch, attached). I hope the comments make clear what I did. It's not much yet. J-. -Oorspronkelijk bericht- From: MarkoMäkelä Sent: Monday, February 07, 2011 10:41 PM To: Development list for mkgmap Subject: Re: [mkgmap-dev] 0x10 for residential in default style On Mon, Feb 07, 2011 at 10:29:12PM +0100, Jeroen Muris wrote: If the polygons styling needs work I'm willing to help. Just let me know what I can do. Basically, suggest some changes, preferrably by sending patches. polygons-1829-JM.patch Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
