patch to correct plazas in default style
Hi, Currently the default style creates a residential road for plazas correctly marked with highway=pedestrian, area=yes. An example of such a plaza can be found here: http://openstreetmap.org/?lat=9.932554&lon=-84.071404&zoom=18&layers=B000FTF A patch to correct this behaviour is attached. Comments are appreciated. Cheers, Ben diff --git a/resources/styles/default/lines b/resources/styles/default/lines index 9594a9a..cc21b2c 100644 --- a/resources/styles/default/lines +++ b/resources/styles/default/lines @@ -24,7 +24,7 @@ highway=footway [0x16 road_class=0 road_speed=0 resolution 23] highway=minor [0x06 road_class=1 road_speed=2 resolution 21] highway=motorway {add oneway = yes } [0x01 road_class=4 road_speed=6 resolution 12] highway=motorway_link [0x01 road_class=4 road_speed=3 resolution 16] -highway=pedestrian [0x06 road_class=0 road_speed=0 resolution 22] +highway=pedestrian & area!=yes [0x06 road_class=0 road_speed=0 resolution 22] highway=primary [0x02 road_class=3 road_speed=4 resolution 19] highway=primary_link [0x03 road_class=3 road_speed=3 resolution 19] highway=residential | highway=living_street [0x06 road_class=0 road_speed=2 resolution 21] @@ -40,7 +40,7 @@ highway=unclassified [0x06 road_class=1 road_speed=2 resolution 21] highway=unsurfaced [0x0a road_class=0 road_speed=1 resolution 21] # Mop up any unrecognised highway types -highway=* [0x07 ] +highway=* & area!=yes [0x07 ] natural=coastline [0x15 resolution 12] power=line [0x29 resolution 20] diff --git a/resources/styles/default/polygons b/resources/styles/default/polygons index 606f26f..74b5d74 100644 --- a/resources/styles/default/polygons +++ b/resources/styles/default/polygons @@ -42,4 +42,9 @@ natural=wood [0x50 resolution 18] place=village [0x03 resolution 18] +# squares and plazas +highway=pedestrian & area=yes [0x17 resolution 20] +# other highways that have area=yes set must be parking lots +highway=* & area=yes [0x05 resolution 21] + waterway=riverbank [0x46 resolution 20]
On Thu, 19 Feb 2009 20:58:23 -0600 Ben Konrath <ben@bagu.org> wrote:
Hi,
Currently the default style creates a residential road for plazas correctly marked with highway=pedestrian, area=yes. An example of such a plaza can be found here:
http://openstreetmap.org/?lat=9.932554&lon=-84.071404&zoom=18&layers=B000FTF
A patch to correct this behaviour is attached. Comments are appreciated.
Cheers, Ben
Tagging an area as a highway, is that commonplace? According to http://wiki.openstreetmap.org/wiki/Map_Features, highways are lines, not areas. However, I don't have a problem with what the patch is doing although I haven't actually tried it out. Cheers, Mark
On Fri, Feb 20, 2009 at 10:53 AM, Mark Burton <markb@ordern.com> wrote:
Tagging an area as a highway, is that commonplace? According to http://wiki.openstreetmap.org/wiki/Map_Features, highways are lines, not areas.
Actually for pedestrian "highways", areas are allowed, in particular for pedestrian squares: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dpedestrian This tagging is particularly common in the down town areas of European cities. I have long hoped for such a patch. :-) I will try it out. Cheers.
Hi Mark, On Fri, Feb 20, 2009 at 3:53 AM, Mark Burton <markb@ordern.com> wrote:
On Thu, 19 Feb 2009 20:58:23 -0600 <snip> Tagging an area as a highway, is that commonplace? According to http://wiki.openstreetmap.org/wiki/Map_Features, highways are lines, not areas.
Yes, as Clinton pointed out, highway=pedestrian, area=yes is correct for plazas and squares. The only strange thing I think I'm doing with the patch is this: # other highways that have area=yes set must be parking lots highway=* & area=yes [0x05 resolution 21] AFAIK, only squares and plazas should use the highway and area tags together but I thought I'd try to be clever and catch some bad tagging. This also ensures all of the highway tags are caught as is the case with the current version of the style. I think that this could be omitted if you don't like it. Cheers, Ben
On Fri, Feb 20, 2009 at 3:58 AM, Ben Konrath <ben@bagu.org> wrote:
Currently the default style creates a residential road for plazas correctly marked with highway=pedestrian, area=yes.
A patch to correct this behaviour is attached. Comments are appreciated.
I manually applied this patch to my custom style files and recompiled my map. I have attached before and after screen shots of such a pedestrian area in Mapsource (the map is using the teddy.typ file from here: http://wiki.openstreetmap.org/index.php/User:Computerteddy). Pedestrian areas are now displayed as "City park" polygons (0x17). This is potentially somewhat confusing, as these pedestrian squares are generally completely paved, or may contain actual city parks. However I am not aware of any other Garmin polygon with an appropriate semantic meaning for this situation. I suppose city park is the best compromise. I'll most likely keep these definitions in my custom style files, but other users may have different opinions on the matter. Thanks for this: the rendering of pedestrian squares as residential roads has always bothered me. :-) Cheers.
Hi Clinton, On Fri, Feb 20, 2009 at 6:49 AM, Clinton Gladstone <clinton.gladstone@googlemail.com> wrote: <snip>
Pedestrian areas are now displayed as "City park" polygons (0x17). This is potentially somewhat confusing, as these pedestrian squares are generally completely paved, or may contain actual city parks. However I am not aware of any other Garmin polygon with an appropriate semantic meaning for this situation. I suppose city park is the best compromise.
Yeah, I agree. I don't really like that the plazas are marked as parks but as you mentioned, there aren't any other suitable Garmin polygons.
I'll most likely keep these definitions in my custom style files, but other users may have different opinions on the matter.
Thanks for this: the rendering of pedestrian squares as residential roads has always bothered me. :-)
Not a problem. But really you should thank whoever made the style system - I think it was Steve - it made this patch easy to make :-) Cheers, Ben
Hi Clinton / Mark, Clinton Gladstone wrote: <snip>
Pedestrian areas are now displayed as "City park" polygons (0x17). This is potentially somewhat confusing, as these pedestrian squares are generally completely paved, or may contain actual city parks. However I am not aware of any other Garmin polygon with an appropriate semantic meaning for this situation. I suppose city park is the best compromise.
I just discovered the "human made area" Garmin polygon (0x13) which seems to be a better choice for these pedestrian squares. An updated patch is attached. Let me know how it works for you. Cheers, Ben diff --git a/resources/styles/default/lines b/resources/styles/default/lines index 9594a9a..cc21b2c 100644 --- a/resources/styles/default/lines +++ b/resources/styles/default/lines @@ -24,7 +24,7 @@ highway=footway [0x16 road_class=0 road_speed=0 resolution 23] highway=minor [0x06 road_class=1 road_speed=2 resolution 21] highway=motorway {add oneway = yes } [0x01 road_class=4 road_speed=6 resolution 12] highway=motorway_link [0x01 road_class=4 road_speed=3 resolution 16] -highway=pedestrian [0x06 road_class=0 road_speed=0 resolution 22] +highway=pedestrian & area!=yes [0x06 road_class=0 road_speed=0 resolution 22] highway=primary [0x02 road_class=3 road_speed=4 resolution 19] highway=primary_link [0x03 road_class=3 road_speed=3 resolution 19] highway=residential | highway=living_street [0x06 road_class=0 road_speed=2 resolution 21] @@ -40,7 +40,7 @@ highway=unclassified [0x06 road_class=1 road_speed=2 resolution 21] highway=unsurfaced [0x0a road_class=0 road_speed=1 resolution 21] # Mop up any unrecognised highway types -highway=* [0x07 ] +highway=* & area!=yes [0x07 ] natural=coastline [0x15 resolution 12] power=line [0x29 resolution 20] diff --git a/resources/styles/default/polygons b/resources/styles/default/polygons index 606f26f..4bda41a 100644 --- a/resources/styles/default/polygons +++ b/resources/styles/default/polygons @@ -42,4 +42,9 @@ natural=wood [0x50 resolution 18] place=village [0x03 resolution 18] +# squares and plazas +highway=pedestrian & area=yes [0x13 resolution 20] +# other highways that have area=yes set must be parking lots +highway=* & area=yes [0x05 resolution 21] + waterway=riverbank [0x46 resolution 20]
On Sat, Feb 21, 2009 at 7:40 AM, Steve Ratcliffe <steve@parabola.demon.co.uk> wrote:
Hi
I just discovered the "human made area" Garmin polygon (0x13) which seems to be a better choice for these pedestrian squares. An updated patch is attached. Let me know how it works for you.
I've applied this version of the patch.
Thanks Steve! Cheers, Ben
On Fri, Feb 20, 2009 at 7:50 PM, Ben Konrath <ben@bagu.org> wrote:
I just discovered the "human made area" Garmin polygon (0x13) which seems to be a better choice for these pedestrian squares. An updated patch is attached. Let me know how it works for you.
Hm... this polygon type (0x13) is not documented in the garmin_feature_list.csv file in the mkgmap resources directory, is it? Where did you find it? I tried out a somewhat different approach for for squares and plazas: I found an unused polygon type (0x1b) and added a tiled bitmap for this polygon to the TYP file I use. The bitmap, with a lot of imagination, represents what I could picture as a flagstoned or cobblestoned area. As well, I added 0x1b to my polygon style file. I have attached a Mapsource screen shot of the result. The screen shot is of Piazza San Pietro in Vatican City. Personally, I think this looks rather nice, but that is a matter of taste and politics. ;-) However, I'm not sure what consequences these polygon types would have for pedestrian/bicycle routing. It would be inconvenient if pedestrians were always routed around plazas and squares as if these areas were impassible obstacles. Cheers.
Hi Clinton, Sorry for the delay, I've been away from the internet for the past week. On Mon, Feb 23, 2009 at 6:36 AM, Clinton Gladstone <clinton.gladstone@googlemail.com> wrote:
On Fri, Feb 20, 2009 at 7:50 PM, Ben Konrath <ben@bagu.org> wrote:
I just discovered the "human made area" Garmin polygon (0x13) which seems to be a better choice for these pedestrian squares. An updated patch is attached. Let me know how it works for you.
Hm... this polygon type (0x13) is not documented in the garmin_feature_list.csv file in the mkgmap resources directory, is it? Where did you find it?
I found it in the cgpsmapper manual - it seems to have more Garmin codes than the garmin_feature_list.csv file. You can find it here: http://www.cgpsmapper.com/download/cGPSmapper-UsrMan-v02.4.3.pdf
I tried out a somewhat different approach for for squares and plazas: I found an unused polygon type (0x1b) and added a tiled bitmap for this polygon to the TYP file I use. The bitmap, with a lot of imagination, represents what I could picture as a flagstoned or cobblestoned area. As well, I added 0x1b to my polygon style file.
I have attached a Mapsource screen shot of the result. The screen shot is of Piazza San Pietro in Vatican City. Personally, I think this looks rather nice, but that is a matter of taste and politics. ;-)
Yeah, I agree, it looks better than what I'm using now.
However, I'm not sure what consequences these polygon types would have for pedestrian/bicycle routing. It would be inconvenient if pedestrians were always routed around plazas and squares as if these areas were impassible obstacles.
That's actually a good point. Giving it a little thought here ... Even if these area were marked as a park, would pedestrians be routed through the area in any direction? That definitely doesn't make sense for the parks or squares I know here in San Jose. I would rather specify the paths in the parks and have the pedestrians routed through those. Thoughts? This all said, perhaps we are getting ahead of ourselves here. So far it seems that most people are using mkgmap to generate maps for driving. Maybe we should revisit this when more people are looking for walking maps. I'm not even sure using a Garmin GPS for pedestrian routing is a normal use case. Maybe that's why we couldn't find an Garmin polygon type to describe plazas and squares correctly. I know I definitely use my GPS when I'm walking around San Jose but it really never occurred to me to use the routing feature for walking probably because I enjoy walking down particular streets for the atmosphere they have or if they are pedestrian friendly (low traffic, have sidewalks, don't smell etc.), not necessarily if it's the best route to my destination. Anyway, just some thoughts here. Cheers, Ben
On Sun, Mar 1, 2009 at 5:23 AM, Ben Konrath <ben@bagu.org> wrote:
Hm... this polygon type (0x13) is not documented in the garmin_feature_list.csv file in the mkgmap resources directory, is it? Where did you find it?
I found it in the cgpsmapper manual - it seems to have more Garmin codes than the garmin_feature_list.csv file.
Is polygon type 0x13 not usually used for buildings? This is what Bernhard Heibler's POI Address + Area POIs v7 patch adds to the polygon style file: +building=yes [0x13 resolution 18] If so, this presents a significant conflict.
However, I'm not sure what consequences these polygon types would have for pedestrian/bicycle routing. It would be inconvenient if pedestrians were always routed around plazas and squares as if these areas were impassible obstacles.
That's actually a good point. Giving it a little thought here ... Even if these area were marked as a park, would pedestrians be routed through the area in any direction? That definitely doesn't make sense for the parks or squares I know here in San Jose. I would rather specify the paths in the parks and have the pedestrians routed through those. Thoughts?
My initial tests in Mapsource indicate that the Garmin routing algorithm only routes along polylines, and never through areas, even if such areas are theoretically navigable by the current mode of transport. I suppose in retrospect, this is quite obvious. At least with the previous solution, with highway=pedestrian in the lines style file, pedestrians should be routed around the edge of the plaza.
This all said, perhaps we are getting ahead of ourselves here. So far it seems that most people are using mkgmap to generate maps for driving. Maybe we should revisit this when more people are looking for walking maps. I'm not even sure using a Garmin GPS for pedestrian routing is a normal use case.
I think you're right: this is most likely something for which Garmin did not design the routing function. I however, do use my device extensively for pedestrian and bicycle navigation. In most circumstances, I can get along fine just using the straight-line navigation, but pedestrian routing would still be a kind of "luxury" feature that would be really nice to have. I would not consider this a high-priority item in any case: this is perhaps left best as a possibility for those who wish to extensively customize the style files to produce specialty maps, such as has been done for the cycling/mtb maps. Cheers.
On Tue, Mar 3, 2009 at 6:26 AM, Clinton Gladstone <clinton.gladstone@googlemail.com> wrote:
On Sun, Mar 1, 2009 at 5:23 AM, Ben Konrath <ben@bagu.org> wrote:
Hm... this polygon type (0x13) is not documented in the garmin_feature_list.csv file in the mkgmap resources directory, is it? Where did you find it?
I found it in the cgpsmapper manual - it seems to have more Garmin codes than the garmin_feature_list.csv file.
Is polygon type 0x13 not usually used for buildings?
This is what Bernhard Heibler's POI Address + Area POIs v7 patch adds to the polygon style file:
+building=yes [0x13 resolution 18]
If so, this presents a significant conflict.
Yes, that's right, 0x13 is being used for buildings too. IIRC, 0x13 is meant for "human-made" stuff but if we want to differentiate buildings from plazas then I think we're back to using 0x17 (parks) which is fine by me. What do you think? Cheers, Ben
On Mon, Mar 9, 2009 at 5:36 PM, Ben Konrath <ben@bagu.org> wrote:
Yes, that's right, 0x13 is being used for buildings too. IIRC, 0x13 is meant for "human-made" stuff but if we want to differentiate buildings from plazas then I think we're back to using 0x17 (parks) which is fine by me. What do you think?
I guess parks is better than buildings, because in many cases, a plaza is either surrounded by buildings (such as St. Peter's Square in Vatican City), or there is a building in the middle of the plaza (such as the Louvre's Pyramid). In these cases, the plaza would be indistinguishable from the buildings. Tweekers can still modify the style file and customize a TYP file to their liking (as I have done), but I think 0x17 is the most sensible default. Cheers.
Clinton Gladstone wrote:
On Mon, Mar 9, 2009 at 5:36 PM, Ben Konrath <ben@bagu.org> wrote:
Yes, that's right, 0x13 is being used for buildings too. IIRC, 0x13 is meant for "human-made" stuff but if we want to differentiate buildings from plazas then I think we're back to using 0x17 (parks) which is fine by me. What do you think?
I guess parks is better than buildings, because in many cases, a plaza is either surrounded by buildings (such as St. Peter's Square in Vatican City), or there is a building in the middle of the plaza (such as the Louvre's Pyramid). In these cases, the plaza would be indistinguishable from the buildings.
Tweekers can still modify the style file and customize a TYP file to their liking (as I have done), but I think 0x17 is the most sensible default.
Sounds good. A patch to change the default for plazas to 0x17 is attached. Cheers, Ben Index: /home/ben/workspace/mkgmap2/resources/styles/default/polygons =================================================================== --- /home/ben/workspace/mkgmap2/resources/styles/default/polygons (revision 974) +++ /home/ben/workspace/mkgmap2/resources/styles/default/polygons (working copy) @@ -48,8 +48,8 @@ place=village [0x03 resolution 18] # squares and plazas -highway=pedestrian & area=yes [0x13 resolution 20] +highway=pedestrian & area=yes [0x17 resolution 20] # other highways that have area=yes set must be parking lots highway=* & area=yes [0x05 resolution 21] waterway=riverbank [0x46 resolution 20]
Hm... this polygon type (0x13) is not documented in the garmin_feature_list.csv file in the mkgmap resources directory, is it? Where did you find it?
I found it in the cgpsmapper manual - it seems to have more Garmin codes than the garmin_feature_list.csv file. You can find it here:
http://www.cgpsmapper.com/download/cGPSmapper-UsrMan-v02.4.3.pdf
I just stumbled over another list of types. Its contained in the cookbook for the maptk programm. (Available only in german) http://www.maptk.dnsalias.com/Docs/Kochbuch.pdf
I tried out a somewhat different approach for for squares and plazas: I found an unused polygon type (0x1b) and added a tiled bitmap for this polygon to the TYP file I use. The bitmap, with a lot of imagination, represents what I could picture as a flagstoned or cobblestoned area. As well, I added 0x1b to my polygon style file.
There is the polygon type 0x1b (page 40) described as pedestrian. So you have choosen a good one :-)
However, I'm not sure what consequences these polygon types would have for pedestrian/bicycle routing. It would be inconvenient if pedestrians were always routed around plazas and squares as if these areas were impassible obstacles.
That's actually a good point. Giving it a little thought here ... Even if these area were marked as a park, would pedestrians be routed through the area in any direction? That definitely doesn't make sense for the parks or squares I know here in San Jose. I would rather specify the paths in the parks and have the pedestrians routed through those. Thoughts?
In the file there is also mentioned a line type 0x0d for pedestrian areas. (page 39) Maybe we need to insert a routable line behind the polyogon?
On Mon, Mar 30, 2009 at 11:52:36PM +0200, Johann Gail wrote:
Hm... this polygon type (0x13) is not documented in the garmin_feature_list.csv file in the mkgmap resources directory, is it? Where did you find it?
I found it in the cgpsmapper manual - it seems to have more Garmin codes than the garmin_feature_list.csv file. You can find it here:
http://www.cgpsmapper.com/download/cGPSmapper-UsrMan-v02.4.3.pdf
I just stumbled over another list of types. Its contained in the cookbook for the maptk programm. (Available only in german)
Luckily, the lists are mostly in English. Hmm, 0x0d ("native american reservate") is listed as both Reservat and Heide. If I remember my German correctly, the latter can mean both a type of land and non-Christian people. :-) Maybe the description can be overridden in the TYP file. Based on the file names in http://maptk.dnsalias.com/MapTk/, it appears to be a Python program. There's also a file for Ubuntu (a derivative of Debian GNU/Linux), but the manual mentions some Windows tools (cgpsmapper, GPSMapEdit). It also mentions mkgmap in section 3.4, discussing different IMG formats. Hmm, page 41 mentions language codes for the TXT fields in TYP files. This would be useful for translating custom POIs. For example, for amenity=recycling, we could define custom POI types and texts listing the acceptable types of materials. Marko
participants (6)
-
Ben Konrath -
Clinton Gladstone -
Johann Gail -
Mark Burton -
Marko Mäkelä -
Steve Ratcliffe