Building vs way in default style
Hi all, I don't know if it's an issue... A map compiled with the default style gives a not very nice rendering for "Barrage Vauban" in Strasbourg (identifier 40 217 747 in OSM). https://tuxdomain.darktech.org/osm-garmin/view.php?file=France/Barrage_Vauba... Building is not rendered. Just the way. And there are bits of building on the banks. Priority problem in the style ? NB : building isn't correctly tagged (building=bridge would be a better tag). Steph
Hi Steph, I think mkgmap creates a shape for the building and another one for the water. It seems that without a type file the water has higher priority. It is possible to detect that situation and cut the shape of the building out of the shape for the water, but that will require a lot of CPU, so I think it's not a good idea. Gerd Stéphane MARTIN wrote
Hi all,
I don't know if it's an issue... A map compiled with the default style gives a not very nice rendering for "Barrage Vauban" in Strasbourg (identifier 40 217 747 in OSM).
https://tuxdomain.darktech.org/osm-garmin/view.php?file=France/Barrage_Vauba...
Building is not rendered. Just the way. And there are bits of building on the banks.
Priority problem in the style ?
NB : building isn't correctly tagged (building=bridge would be a better tag).
Steph _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Building-vs-way-in-default-style-tp5805279p58... Sent from the Mkgmap Development mailing list archive at Nabble.com.
On Mon, May 05, 2014 at 12:58:58PM -0700, GerdP wrote:
Hi Steph,
I think mkgmap creates a shape for the building and another one for the water. It seems that without a type file the water has higher priority. It is possible to detect that situation and cut the shape of the building out of the shape for the water, but that will require a lot of CPU, so I think it's not a good idea.
After looking at http://www.openstreetmap.org/way/40217747 I have to agree that we should not do this by default. It could be misleading to cut out bridge polygons from the waters that they are crossing. Someone who uses the map for kayak navigation (or, say, ice-skating or cross-country skiing in the winter) could want to see the water polygon without any gaps, if the bridge is high enough. I think that ideally, there should be multiple map layers, enabled or disabled by the user. The base layer would contain the natural=* or landuse=*, and a special "man-made objects" layer would show building=* and man_made=* on top of the base layer. This is doable with the Garmin format (in mkgmap by using one style per output layer). Marko
This issue can simply be solved by using a TYP file. You can grab the default style typ file that we use in Lambertus generic OSM maps: https://code.google.com/p/mkgmap-style-sheets/source/browse/#svn%2Ftrunk%2Ft... The strange thing is that Garmin doesn't seem to recognize the building poygons type 0x13. It is rendered as a white "unknown area" on Basecamp as well as Mapsource. And as Gerd says it is rendered under the water polygons (in most typ files it is always on top). Does anyone know which typ Garmin is using in its own maps for buildings? Or do they use a Typ file by default (with modern devices and many map details on OSM this is imho a must).
Hi, Thanks all. I'll watch it. Le 06/05/2014 05:16, Minko a écrit :
This issue can simply be solved by using a TYP file. You can grab the default style typ file that we use in Lambertus generic OSM maps: https://code.google.com/p/mkgmap-style-sheets/source/browse/#svn%2Ftrunk%2Ft...
The strange thing is that Garmin doesn't seem to recognize the building poygons type 0x13. It is rendered as a white "unknown area" on Basecamp as well as Mapsource. And as Gerd says it is rendered under the water polygons (in most typ files it is always on top).
Does anyone know which typ Garmin is using in its own maps for buildings? Or do they use a Typ file by default (with modern devices and many map details on OSM this is imho a must).
Latest NT Topo TYP files use both 0x13 and 0x109 for buildings. Interestingly, only 109 seems to be visible. So, I wonder why 0x13 has been included perhaps for some compatibility reason. -- View this message in context: http://gis.19327.n5.nabble.com/Building-vs-way-in-default-style-tp5805279p58... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, Le 06/05/2014 14:08, nwillink a écrit :
Latest NT Topo TYP files use both 0x13 and 0x109 for buildings. Interestingly, only 109 seems to be visible. So, I wonder why 0x13 has been included perhaps for some compatibility reason.
That is the solution. 0x10900 works fine on etrex30. Thank you very much.
I'm glad that works! On 06/05/2014 20:42, Stéphane MARTIN [via GIS] wrote:
Hi,
Le 06/05/2014 14:08, nwillink a écrit :
Latest NT Topo TYP files use both 0x13 and 0x109 for buildings. Interestingly, only 109 seems to be visible. So, I wonder why 0x13 has been included perhaps for some compatibility reason.
That is the solution. 0x10900 works fine on etrex30.
Thank you very much. _______________________________________________ mkgmap-dev mailing list [hidden email] </user/SendEmail.jtp?type=node&node=5805419&i=0> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
------------------------------------------------------------------------ If you reply to this email, your message will be added to the discussion below: http://gis.19327.n5.nabble.com/Building-vs-way-in-default-style-tp5805279p58...
To unsubscribe from Building vs way in default style, click here <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5805279&code=b3NtQHBpbm5zLmNvLnVrfDU4MDUyNzl8MTM1NTM3MTE1MQ==>. NAML <http://gis.19327.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
-- View this message in context: http://gis.19327.n5.nabble.com/Building-vs-way-in-default-style-tp5805279p58... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Interesting, type 0x10900 displays the contours of the buildings on a Dakota and Oregon. See https://www.dropbox.com/sh/ly8vyjamajxw1s9/QWBW9cxmWt/type_109.bmp On Mapsource and Basecamp it's the same almost invisible white area as 0x13 though, but on the newer GPS units it's definitely an improvement. On an older nüvi its also well visible (no 3D effect though), how about on some older units? If typ 0x10900 is visible too, maybe it's worth to change type 0x13 for 0x10900 in the default style?
On 06/05/2014 20:42, Stéphane MARTIN [via GIS] wrote: Hi,
Le 06/05/2014 14:08, nwillink a écrit :
Latest NT Topo TYP files use both 0x13 and 0x109 for buildings. Interestingly, only 109 seems to be visible. So, I wonder why 0x13 has been included perhaps for some compatibility reason.
That is the solution. 0x10900 works fine on etrex30.
Hi Minko The plot thickens as lines 0x10900 ,10901,10902 are also used as 'backups' for 0x20,0x21,0x22, ie contours. -- View this message in context: http://gis.19327.n5.nabble.com/Building-vs-way-in-default-style-tp5805279p58... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi, Works on (old) etrex Vista Cx ! Le 06/05/2014 17:03, nwillink a écrit :
I'm glad that works!
On 06/05/2014 20:42, Stéphane MARTIN [via GIS] wrote:
Hi,
Le 06/05/2014 14:08, nwillink a écrit :
Latest NT Topo TYP files use both 0x13 and 0x109 for buildings. Interestingly, only 109 seems to be visible. So, I wonder why 0x13 has been included perhaps for some compatibility reason.
That is the solution. 0x10900 works fine on etrex30.
Thank you very much.
participants (5)
-
GerdP -
Marko Mäkelä -
Minko -
nwillink -
Stéphane MARTIN