Re: [osmosis-dev] Updating database with partial data
Hi Brett, First of all thank you for answering! The complete command line I’ve been using to start this process is: CALL C:\Java\OSM\osmosis\v.0.43\bin\osmosis -v --read-xml file=belgium-latest.osm.bz2 --log-progress interval=5 label=BELGIUM --write-pgsql host= user= database= password=x You’re quite right when addressing the “flag” for updating the pgsnapshot! I’m already reviewing the update process! So duplicates are certainly due to not using the update functionality! Regarding the merge of the files, this isn’t an option, for now, due to the incremental steps to my DB! This being said, I’m importing one country and afterwards another, repeating the process until I have the planet! Managing all the files and storage for everything is not an option at this point! I’m doing like this to produce a “proof of concept” on OSM data Best regards, Nuno From: Brett Henderson [mailto:br...@bretth.com] Sent: domingo, 13 de Outubro de 2013 12:02 Hi Nuno, On 10 October 2013 22:18, Nuno Miguel Lourenço nuno-miguel-loure...@telecom.ptmailto:nuno-miguel-loure...@telecom.pt wrote: Hi, I’m updating a OpenStreetMaps based DB, but we are doing incremental steps to the DB data. We are importing just a few countries and then proceed to continents and at the end the planet file. We are already using the country data! NOTE: The countries are not neighbors! We are importing some Europe countries from http://download.geofabrik.de/europe.html getting the several .osm.pbf files for the ones we want! We are coming across an issue… We are getting a lot of Detail: Key (id)=(x) is duplicated.; nested exception is org.postgresql.util.PSQLException: ERROR: could not create unique index pk_relations We are getting this for the relations table, for the nodes, ways tables also!!! It sounds like your .osm.pbf files contain duplicate data. The countries may not be neighbours, but there may still be data relationships that connect them. I assume (providing your exact command line and exception messages would be very helpful) you're trying to use a task like --write-pgsql which assumes that the database is empty. In your case you're trying to run it multiple times against a non-empty database which will fail if the input files contain duplicate data. Is there any way we can avoid this? Perhaps. Combining all .osm.pdf files together into a single file and remove duplicate data before importing should fix it. We tried to remove the duplicates on the osmosisUpdate function but it did not work due to this being called after all the pushes of data to the DB. The osmosisUpdate function is only called by the --write-pgsql-change task, but I don't believe you're using that task ... Is there any other way to do this with osmosis? Merge all the .osm.pbf files together before importing. Merging the several .osm.pbf files to generate a unique one is not a solution. Okay. Can you please explain why this is not an option? Brett ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/osmosis-dev
[OSM-dev] pgmapcss 0.4.0 released!
Hi! The last month I spent on harmonizing pgmapcss with the MapCSS 0.2 specification. Finally the rendering order and most MapCSS parameters follow this standard. Also there were many bug fixes, most notably a re-implementation of the eval()-parser which was really buggy. When loading a MapCSS style you have to specify if you are using Mapnik 2.0 or Mapnik 2.2 - Mapnik 2.2 can read more properties from database columns, therefore a smaller pre-processed Mapnik-file is possible (and more properties may be the result of an eval()-statement). I also updated the installation instructions, now it should be possible to get to a rendered image in a couple of minutes :-) There are a couple of things which are not possible yet (or need a lot of work), notably coloured shield backgrounds and extrude-*. Also note that pgmapcss depends on a osm2pgsql based database (with hstore column), which usually does not contain all OSM data. Get the source: https://github.com/plepe/pgmapcss/ Have fun! Please report issues on Github. greetings, Stephan -- Seid unbequem, seid Sand, nicht Öl im Getriebe der Welt! - Günther Eich ,-. | Stephan Bösch-Plepelits,| | Technische Universität Wien -Studien Informatik Raumplanung | | Projects: | | openstreetbrowser.org couchsurfing.org tubasis.at bl.mud.at | | Contact:| | Mail: sk...@xover.mud.at Blog: plepe.at | | Twitter: twitter.com/plepe Jabber: sk...@jabber.at | `-' ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] wrong redering of tunnels on the main site after the change of rendering rules
Hello, while the weekend I stumbled accross the old Elbe tunnel at Hamburg https://de.wikipedia.org/wiki/St._Pauli-Elbtunnel https://en.wikipedia.org/wiki/Elbe_Tunnel_%281911%29 and how it is rendered on the main OSM site (mapnik style): http://www.openstreetmap.org/?mlat=53.5439mlon=9.9665#map=16/53.5439/9.9665 It looks like a road going above the water... :-( For me the tagging seems to be all right (level, tunnel, etc, all is set) but maybe that the new rendering rules are not correct when the tunnel is below water? Could someone please investigate? Thanks. Best regards, Michael. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] wrong redering of tunnels on the main site after the change of rendering rules
On 2013-10-14 10:34, Michael Kugelmann wrote: Hello, while the weekend I stumbled accross the old Elbe tunnel at Hamburg https://de.wikipedia.org/wiki/St._Pauli-Elbtunnel https://en.wikipedia.org/wiki/Elbe_Tunnel_%281911%29 and how it is rendered on the main OSM site (mapnik style): http://www.openstreetmap.org/?mlat=53.5439mlon=9.9665#map=16/53.5439/9.9665 It looks like a road going above the water... :-( For me the tagging seems to be all right (level, tunnel, etc, all is set) but maybe that the new rendering rules are not correct when the tunnel is below water? Could someone please investigate? Thanks. What do you expect to see? That the tunnel is not rendered when it is below a waterbody? That has never been the case. Tunnels under water have always been rendered the same way they look when under a landmass: lighter in color and dashed lines. Compare the Zeeburgertunnel in Amsterdam (natural=coastline): http://www.openstreetmap.org/?mlat=53.5439mlon=9.9665#map=16/52.3737/4.9748 Or the Gouwe-Aquaduct (natural=water) http://www.openstreetmap.org/?mlat=53.5439mlon=9.9665#map=19/52.02548/4.66688 Regards, Maarten ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Server configuration: (Urgent problem) pink tiles while requesting lvl 16, 17 18 tiles
Hello, everybody.I am facing an strange issue. A co-worker set up a tile server for a client by using the instructions on this link:http://switch2osm.org/serving-tiles/building-a-tile-server-from-packages/This co-worker isn't working with us anymore, and I am currently facing an urgent problem. Requested tiles from levels 16, 17 and 18 from zones that have never been visited (the app was being used in very restricted areas and now different zones have been enabled) are showing as pink squares. I have read that these kind of requests may fail but they were supposed to be queued and ready to be served after some time. It is not happening. However, zones that users have been using previously, they work just fine (i.e.http://tile.vaivengtc.com/osm/18/126499/102473.png).You can take a look at the server here:http://tile.vaivengtc.com/osm/slippymap.htmlI have been googling the problem for the whole day and all I found was a firefox bug, which is not my case since it is happening in all the browsers, and this:https://help.openstreetmap.org/questions/16050/pink-tiles-instead-of-mapwhich is not my case neither, since the tile's URL seems to be ok.Since I have never managed this server before, I am scared about making any change because it is a production server, so I need it to be up and running while I solve this problem.Can someone shed some light on my problem? Maybe pointing out to some helpful link? I would appreciate any help, since I need to solve this issue before next thursday. Best regards,Álvaro Enríquez de Luna Muñoz - CTOwww.many-worlds.ese-mail: aenriquezdel...@many-worlds.esPhone: +34 675 933 744 / +34 911 298 111Augmented Reality Technology ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] parameterization of mapnik style-sheets in mod_tile / renderd and multi-lingual maps
Hello everyone, I would like to mention that I have committed a new feature to mod_tile / renderd and would appreciate any feedback or comments. Mod_tile and renderd are now prepared for the possibility to parameterize the mapnik style-sheet on the fly on a (meta)tile by (metatile) basis. For this purpose, the URL schema for tileservers was extended. It now takes the form: https://my.tile.server/style/parameters/z/x/y.ext parameters is an arbitrary string that gets passed on to renderd and can be used to parameterize the style-sheet for that rendering request. The first use for this functionality is to make it easy to offer multi-lingual maps. I.e. to be able to specify (parameterize) the language in which the names should appear on the map. E.g. one can specify that English names (name:en) should be used instead of the plain name tag. This is heavily based upon Jochen Topf's work on the multi-lingual project for wikimedia [1,2], that has shown the feasibility of this concept. By integrating it into mod_tile / renderd and making it trivial to enable, it will hopefully see wider adoption and prove useful to a bigger audience. You can specify an ordering of name tags to be used when trying to render any labels. E.g. de,en,_ will use name:de if available, otherwise try name:en and finally use name if neither name:de or name:en is available. Technically, renderd will take the stylesheet it loads and replace name in the sql queries with coalesce(tags-'name:de', tags-'name:en', tags-'name') as name. Everything should be backwards compatible and one can activate this feature on a style-by-style basis. If not activated, the old URL schema continues to be used. So e.g. a server can support https://my.tile.server/osm/0/0/0.png and https://my.tile.server/osm-multilingua/de,en,_/0/0/0.png. To make this possible, the protocol between mod_tile and renderd was extended to include the parameterization string (as well as pass through mime information for future purposes, e.g. to be able to render both png and jpg). However, again, everything (both mod_tile and renderd) should be backwards compatible. I.e. renderd can receive rendering requests with the previous version of the protocol, in case you only want to update renderd and still have an older version of mod_tile (or indeed another server software or utility for issuing render requests). Likewise, mod_tile can still send the requests in the previous protocol, and indeed will do so by default unless the parameterization feature is explicitly activated for the given style. This should ensure compatibility with tirex, that has not yet been updated to the change in protocol. Although its first use is for the multi-lingual maps, hopefully this feature can be used for other purposes as well. You still need to write code to interpret the parameterization string and apply the transformation to the mapnik stylesheet object, but given that is all encapsulated in a separate file, this will hopefully be relatively easy if one needs it. Kai [1] http://blog.jochentopf.com/2012-06-21-wikipedia-multilingual-maps-project.html [2] http://blog.jochentopf.com/2012-12-19-status-of-the-multilingual-maps-project.html ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Server configuration: (Urgent problem) pink tiles while requesting lvl 16, 17 18 tiles
On 14 October 2013 17:20, Álvaro Enríquez de Luna Muñoz aenriquezdel...@many-worlds.es wrote: This co-worker isn't working with us anymore, and I am currently facing an urgent problem. Requested tiles from levels 16, 17 and 18 from zones that have never been visited (the app was being used in very restricted areas and now different zones have been enabled) are showing as pink squares. Hi there, It sounds to me like your rendering daemon has died - either renderd, or tirex, depending on your original setup. Without the rendering daemon mod_tile will continue to serve tiles that it has rendered already, but cannot request rendering of any new tiles. The default appearance of missing tiles on OpenLayers is a (nasty) pink background, which again sounds like it fits your situation. Cheers, Andy ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Server configuration: (Urgent problem) pink tiles while requesting lvl 16, 17 18 tiles
If you can have a look in the tile server (apache ?) error log, you'll probably find some clues. Look at /var/log/apache2/error.log Yves Andy Allan gravityst...@gmail.com a écrit : On 14 October 2013 17:20, Álvaro Enríquez de Luna Muñoz aenriquezdel...@many-worlds.es wrote: This co-worker isn't working with us anymore, and I am currently facing an urgent problem. Requested tiles from levels 16, 17 and 18 from zones that have never been visited (the app was being used in very restricted areas and now different zones have been enabled) are showing as pink squares. Hi there, It sounds to me like your rendering daemon has died - either renderd, or tirex, depending on your original setup. Without the rendering daemon mod_tile will continue to serve tiles that it has rendered already, but cannot request rendering of any new tiles. The default appearance of missing tiles on OpenLayers is a (nasty) pink background, which again sounds like it fits your situation. Cheers, Andy ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] parameterization of mapnik style-sheets in mod_tile / renderd and multi-lingual maps
Could this feature be used to pass a font-scaling value from the URL to mod_tile assuming that such a scaling value can be used to affect the font sizes rendered in the resulting tile? I'm thinking like .../style/2/z/x/... for instance to double the size of the fonts. This would be very handy to provide for rendering tiles for higher-dpi devices and keeping them readable. Also, are the resulting rendered meta-tiles automatically segregated in the mapnik/apache file store? I sure hope so or there'll be a serious mess of mixed-rendered tiles all under a tree like default. Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32 On 10/14/2013 12:40 PM, Kai Krueger wrote: Hello everyone, I would like to mention that I have committed a new feature to mod_tile / renderd and would appreciate any feedback or comments. Mod_tile and renderd are now prepared for the possibility to parameterize the mapnik style-sheet on the fly on a (meta)tile by (metatile) basis. For this purpose, the URL schema for tileservers was extended. It now takes the form: https://my.tile.server/style/parameters/z/x/y.ext parameters is an arbitrary string that gets passed on to renderd and can be used to parameterize the style-sheet for that rendering request. The first use for this functionality is to make it easy to offer multi-lingual maps. I.e. to be able to specify (parameterize) the language in which the names should appear on the map. E.g. one can specify that English names (name:en) should be used instead of the plain name tag. This is heavily based upon Jochen Topf's work on the multi-lingual project for wikimedia [1,2], that has shown the feasibility of this concept. By integrating it into mod_tile / renderd and making it trivial to enable, it will hopefully see wider adoption and prove useful to a bigger audience. You can specify an ordering of name tags to be used when trying to render any labels. E.g. de,en,_ will use name:de if available, otherwise try name:en and finally use name if neither name:de or name:en is available. Technically, renderd will take the stylesheet it loads and replace name in the sql queries with coalesce(tags-'name:de', tags-'name:en', tags-'name') as name. Everything should be backwards compatible and one can activate this feature on a style-by-style basis. If not activated, the old URL schema continues to be used. So e.g. a server can support https://my.tile.server/osm/0/0/0.png and https://my.tile.server/osm-multilingua/de,en,_/0/0/0.png. To make this possible, the protocol between mod_tile and renderd was extended to include the parameterization string (as well as pass through mime information for future purposes, e.g. to be able to render both png and jpg). However, again, everything (both mod_tile and renderd) should be backwards compatible. I.e. renderd can receive rendering requests with the previous version of the protocol, in case you only want to update renderd and still have an older version of mod_tile (or indeed another server software or utility for issuing render requests). Likewise, mod_tile can still send the requests in the previous protocol, and indeed will do so by default unless the parameterization feature is explicitly activated for the given style. This should ensure compatibility with tirex, that has not yet been updated to the change in protocol. Although its first use is for the multi-lingual maps, hopefully this feature can be used for other purposes as well. You still need to write code to interpret the parameterization string and apply the transformation to the mapnik stylesheet object, but given that is all encapsulated in a separate file, this will hopefully be relatively easy if one needs it. Kai [1] http://blog.jochentopf.com/2012-06-21-wikipedia-multilingual-maps-project.html [2] http://blog.jochentopf.com/2012-12-19-status-of-the-multilingual-maps-project.html ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Server configuration: (Urgent problem) pink tiles while requesting lvl 16, 17 18 tiles
And search your syslog for any renderd entries that might provide other clues. Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32 On 10/14/2013 1:02 PM, Yves wrote: If you can have a look in the tile server (apache ?) error log, you'll probably find some clues. Look at /var/log/apache2/error.log Yves Andy Allan gravityst...@gmail.com a écrit : On 14 October 2013 17:20, Álvaro Enríquez de Luna Muñoz aenriquezdel...@many-worlds.es wrote: This co-worker isn't working with us anymore, and I am currently facing an urgent problem. Requested tiles from levels 16, 17 and 18 from zones that have never been visited (the app was being used in very restricted areas and now different zones have been enabled) are showing as pink squares. Hi there, It sounds to me like your rendering daemon has died - either renderd, or tirex, depending on your original setup. Without the rendering daemon mod_tile will continue to serve tiles that it has rendered already, but cannot request rendering of any new tiles. The default appearance of missing tiles on OpenLayers is a (nasty) pink background, which again sounds like it fits your situation. Cheers, Andy dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [Tile-serving] parameterization of mapnik style-sheets in mod_tile / renderd and multi-lingual maps
On 10/14/2013 11:59 AM, Lynn W. Deffenbaugh (Mr) wrote: Could this feature be used to pass a font-scaling value from the URL to mod_tile assuming that such a scaling value can be used to affect the font sizes rendered in the resulting tile? I'm thinking like .../style/2/z/x/... for instance to double the size of the fonts. This would be very handy to provide for rendering tiles for higher-dpi devices and keeping them readable. Yes, it should be possible. All you need to do is write a function that takes a mapnik::Map object and a parameterization string and returns a transformed mapnik:Map object. As the font size is presumably specified in the style-sheet you should be able to do that with little problem. You can find the example for the multi-lingual parameterization in https://github.com/openstreetmap/mod_tile/blob/master/src/parameterize_style.cpp Note: for different resolution tiles, you can already change that in mod_tile / renderd with a simple parameter in the renderd.conf ( TILESIZE=512 ), but that is only on a style-by-style basis and not a tile-by-tile basis. Also, are the resulting rendered meta-tiles automatically segregated in the mapnik/apache file store? I sure hope so or there'll be a serious mess of mixed-rendered tiles all under a tree like default. Yes, they are segregated, at least in the file storage backend. I haven't yet updated the rados / ceph storage backend, but I'll fix that soon and I am not sure anyone is actually using that backend. For the filesystem storage backend, it uses the following schema to store it: /base/tile/dir/style/z/xxyy/xxyy/xxyy/xxyy/xxyy.parameterisation.meta i.e. the parameterisation string is part of the metatile filename and all different parameterisations live in the same sub directory. Putting the parameterisation into the filename, rather than as its own subdirectory, should make it easier to expire and delete files, as all files for one (geographic) tile are in the same directory. Kai Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32 On 10/14/2013 12:40 PM, Kai Krueger wrote: Hello everyone, I would like to mention that I have committed a new feature to mod_tile / renderd and would appreciate any feedback or comments. Mod_tile and renderd are now prepared for the possibility to parameterize the mapnik style-sheet on the fly on a (meta)tile by (metatile) basis. For this purpose, the URL schema for tileservers was extended. It now takes the form: https://my.tile.server/style/parameters/z/x/y.ext parameters is an arbitrary string that gets passed on to renderd and can be used to parameterize the style-sheet for that rendering request. The first use for this functionality is to make it easy to offer multi-lingual maps. I.e. to be able to specify (parameterize) the language in which the names should appear on the map. E.g. one can specify that English names (name:en) should be used instead of the plain name tag. This is heavily based upon Jochen Topf's work on the multi-lingual project for wikimedia [1,2], that has shown the feasibility of this concept. By integrating it into mod_tile / renderd and making it trivial to enable, it will hopefully see wider adoption and prove useful to a bigger audience. You can specify an ordering of name tags to be used when trying to render any labels. E.g. de,en,_ will use name:de if available, otherwise try name:en and finally use name if neither name:de or name:en is available. Technically, renderd will take the stylesheet it loads and replace name in the sql queries with coalesce(tags-'name:de', tags-'name:en', tags-'name') as name. Everything should be backwards compatible and one can activate this feature on a style-by-style basis. If not activated, the old URL schema continues to be used. So e.g. a server can support https://my.tile.server/osm/0/0/0.png and https://my.tile.server/osm-multilingua/de,en,_/0/0/0.png. To make this possible, the protocol between mod_tile and renderd was extended to include the parameterization string (as well as pass through mime information for future purposes, e.g. to be able to render both png and jpg). However, again, everything (both mod_tile and renderd) should be backwards compatible. I.e. renderd can receive rendering requests with the previous version of the protocol, in case you only want to update renderd and still have an older version of mod_tile (or indeed another server software or utility for issuing render requests). Likewise, mod_tile can still send the requests in the previous protocol, and indeed will do so by default unless the parameterization feature is explicitly activated for the given style. This should ensure compatibility with tirex, that has not yet been updated to the change in protocol. Although its first use is for the multi-lingual maps, hopefully this feature can be used for other purposes as well. You still need to write code to interpret
Re: [OSM-dev] Server configuration: (Urgent problem) pink tiles while requesting lvl 16, 17 18 tiles
On Monday 14 October 2013, Álvaro Enríquez de Luna Muñoz wrote: (Urgent problem) If this really is urgent, I would suggest trying IRC (particularly #osm-dev on OFTC) may get you help quicker. robert. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] wrong redering of tunnels on the main site after the change of rendering rules
On 14.10.2013 10:52, Maarten Deen wrote: On 2013-10-14 10:34, Michael Kugelmann wrote: Hello, while the weekend I stumbled accross the old Elbe tunnel at Hamburg https://de.wikipedia.org/wiki/St._Pauli-Elbtunnel https://en.wikipedia.org/wiki/Elbe_Tunnel_%281911%29 and how it is rendered on the main OSM site (mapnik style): http://www.openstreetmap.org/?mlat=53.5439mlon=9.9665#map=16/53.5439/9.9665 It looks like a road going above the water... :-( For me the tagging seems to be all right (level, tunnel, etc, all is set) but maybe that the new rendering rules are not correct when the tunnel is below water? Could someone please investigate? Thanks. What do you expect to see? That the tunnel is not rendered when it is below a waterbody? Usually tunnels only have a very blurred/bright color. Please have a look to a normal tunnel like eg. the Engelbergtunnel: http://www.openstreetmap.org/?mlat=48.7933mlon=9.0237#map=15/48.7933/9.0237 https://de.wikipedia.org/wiki/Engelbergtunnel https://en.wikipedia.org/wiki/Engelberg_Tunnel There the tunnel can hardle be seen on the rendering. In the case of the Elbe Tunnel (under water) the road has the same (or almost the same) color as it would be above the water. For me this really confuses. That has never been the case. Tunnels under water have always been rendered the same way they look when under a landmass: lighter in color and dashed lines. Please compare Engelbergtunnel (landmass) to Elbe-Tunnel. This can't be the same. Maybe the additional access control flags on the Elbe Tunnel cause the problem, I don't know. Compare the Zeeburgertunnel in Amsterdam (natural=coastline): http://www.openstreetmap.org/?mlat=53.5439mlon=9.9665#map=16/52.3737/4.9748 Or the Gouwe-Aquaduct (natural=water) http://www.openstreetmap.org/?mlat=53.5439mlon=9.9665#map=19/52.02548/4.66688 both are fine but could be even a litte more bright (IMHO). But if you compare these two against the Elbe-Tunnel you can see that the Elbe tunnel is not at all that bright and hidden. Best regars, Michael. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] wrong redering of tunnels on the main site after the change of rendering rules
On 2013-10-15 04:51, Michael Kugelmann wrote: On 14.10.2013 10:52, Maarten Deen wrote: On 2013-10-14 10:34, Michael Kugelmann wrote: Hello, while the weekend I stumbled accross the old Elbe tunnel at Hamburg https://de.wikipedia.org/wiki/St._Pauli-Elbtunnel https://en.wikipedia.org/wiki/Elbe_Tunnel_%281911%29 and how it is rendered on the main OSM site (mapnik style): http://www.openstreetmap.org/?mlat=53.5439mlon=9.9665#map=16/53.5439/9.9665 It looks like a road going above the water... :-( For me the tagging seems to be all right (level, tunnel, etc, all is set) but maybe that the new rendering rules are not correct when the tunnel is below water? Could someone please investigate? Thanks. What do you expect to see? That the tunnel is not rendered when it is below a waterbody? Usually tunnels only have a very blurred/bright color. Please have a look to a normal tunnel like eg. the Engelbergtunnel: http://www.openstreetmap.org/?mlat=48.7933mlon=9.0237#map=15/48.7933/9.0237 https://de.wikipedia.org/wiki/Engelbergtunnel https://en.wikipedia.org/wiki/Engelberg_Tunnel There the tunnel can hardle be seen on the rendering. In the case of the Elbe Tunnel (under water) the road has the same (or almost the same) color as it would be above the water. For me this really confuses. That has never been the case. Tunnels under water have always been rendered the same way they look when under a landmass: lighter in color and dashed lines. Please compare Engelbergtunnel (landmass) to Elbe-Tunnel. This can't be the same. Maybe the additional access control flags on the Elbe Tunnel cause the problem, I don't know. Compare the Zeeburgertunnel in Amsterdam (natural=coastline): http://www.openstreetmap.org/?mlat=53.5439mlon=9.9665#map=16/52.3737/4.9748 Or the Gouwe-Aquaduct (natural=water) http://www.openstreetmap.org/?mlat=53.5439mlon=9.9665#map=19/52.02548/4.66688 both are fine but could be even a litte more bright (IMHO). But if you compare these two against the Elbe-Tunnel you can see that the Elbe tunnel is not at all that bright and hidden. If you look closely, you'll see that the colors do differ and that the line at the edge is dashed. It is probably because it is a tertiary road which is rendered in light yellow that the difference is small. Normal tertiary road is rendered in #F8F8BA, as a tunnel it is #F9F9D0. The difference is small, but it is present. Maybe the difference in color could be greater, but that's the only issue that exisits. It is rendered differently. Regards, Maarten ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
