Mapnik does not use modified geometry for rendering #903
Comments
|
Author: osm[at]deelkar.net Mapnik does not update immediately, the database is synced once a week, usually wednesdays, so your changes will be visible in about one week on the mapnik map. you can switch to the osmarender view (which is usually more current) via the small (+) at the top right of the map. |
|
Author: fsteggink I've just read about the weekly dump, and given the situation it is possible (and even likely) that my changes were uploaded when the dump was made. This is true if the dump starts at 01.00 GMT (time zone not mentioned at http://wiki.openstreetmap.org/index.php/Planet.osm). My changes were uploaded at about 9 PM EST Tuesday evening, which would correspond to 1 AM GMT. |
|
Author: tom[at]compton.nu It starts at 0111 UK local time, which is equivalent to 0011 GMT at the moment. It does however take a number of hours to run, so changes made shortly after that time may or may not appear in the dump depending on what point the dump has reached when the change is made. |
|
Author: fsteggink So, with regard to the time it is possible that uploads interfere with the weekly dump. I'll wait for next week's rendering if the error is still there. It also seems better that uploads should not take place during the dump. However, I still don't understand one thing, and I hope you are willing to explain it. Why is the geometry in the Mapnik rendering not yet reflecting my changes, but the attribute (key/value pairs) changes are reflecting the new situation? Is the dump being performed in two (or more) parts? First, all geometries are dumped, and when that is complete, the attributes are dumped. In that case my upload might have occurred between those parts, and that will explain the inconsistent situation. Thanks in advance. |
|
Author: tom[at]compton.nu They don't interfere as such, but people wouldn't like it if we blocked uploads for several hours while we dumped the database so instead we have dumps which are not entirely consistent and the renderer copes with that. To answer your specific question, the answer is basically yes. To be precise nodes are dumped separately from ways so it sounds like your nodes were dumped before you made the change and hence hadn't moved, but by the time the dumper got to the ways you had made your changes and the dumper got the new version of the ways. It's not a question of geometries vs attributes - that is a misunderstanding of our data model. The nodes are dumped first, complete with their positions (in lat/lon terms) and tags (ie attributes) then the ways (which are just an ordered list of node ids) are dumped with their list of nodes and their tags (attributes). |
Reporter: fsteggink
[Submitted to the original trac issue database at 1.24pm, Thursday, 15th May 2008]
Hi,
I'm a new OSM user, and I don't know if this bug has been reported before. In that case I apologize. Since this bug is clearly visible, I guess it has not been reported before.
I've split up a couple of streets near Quebec City, Canada, with JSOM. The reason is that I wanted to updat the highway and ref attributes of parts of these streets, to reflect the correct situation.
However, the following day I checked OSM, and I noticed the situation was different from what I expected! Luckily I also used Informationfreeway.org (?) to update one tile, and Osmarender has indeed rerendered that tile, and this was done correctly. (Last night, Osmarender has updated the rest of the tiles near Quebec City.) Also, after I downloaded this part again with JSOM, also the source data seems to be correct. (This was even done on a different machine.) So, this leads me to the conclusion that there might be a problem with Mapnik. Since I'm a new user, I haven't tried out Mapnik myself.
Here is an example. Go to http://www.openstreetmap.org/?lat=46.8459&lon=-71.2045&zoom=12&layers=B0FTT
In the middle you'll see the north lane of a "trunk" road with number 138. However, it should be a motorway with number 40 or 440. (The original segment has been split up in three parts. The south lane is also wrong, but because how this bug affects the rendering, it is not nearly as visible.) The highway="trunk" and ref="138" attributes are only valid for the part of this road north of the bridge. (The bridge road is also split up, and it shows the same problem, like a couple of other roads near Quebec City, which have been modified by me.)
Here is the intersection near the bridge in more detail:
http://www.openstreetmap.org/?lat=46.88262&lon=-71.14478&zoom=16&layers=B0FTT
Both lanes should have the attributes highway="trunk" and ref="138" north of the bridge (where the ramps join the main road at the north side of the intersection), and highway="motorway" and ref="40" south of the bridge and during the intersection. See the Osmarender rendering for the correct representation.
I've looked at the OSM data, which was downloaded from the server, and saved with JSOM. It turns out that the old segment ID is still used for one of the parts of the original segment. So I guess that Mapnik does not update geometries before a rendering, but it updates the attributes only.
It is also possible that my workflow is not correct, but that the old segment should be entirely duplicated, so the ID is not reused. I haven't seen a way to copy roads with JSOM. Maybe extrusions are the way to go? But redrawing or moving geometries is much more inaccurate than splitting a geometry in two, because in the latter case no coordinates are changed (unless it is necessary to insert a new node at the intersection).
Note that I'll intend to change this data soon, so there is a chance that this data will be modified (although I'll add new data). I assume that it is possible to get the original data (before my modifications) from a backup. It is not necessary to restore the backup (if I'm correct), because JOSM and Osmarender show the new situation correctly.
The text was updated successfully, but these errors were encountered: