Re: [OSM-talk] Postmortem analysys
Matt Amos wrote: On Sun, Jan 9, 2011 at 12:09 PM, Lester Caine wrote: > The original decision that there should be no duplicate nodes simply ignored > many of the arguments that there are very good reasons for needing them, > then tools like the duplicate nodes map ASSUME that the decision takes > priority rather than allowing 'duplicates' which are distinguished due to > their elevation? the duplicate nodes map doesn't assume that all duplicates are errors (http://matt.dev.openstreetmap.org/dupe_nodes/about.html#errors). it's simply a tool for finding them - because most of them are errors, - and it's nice to have tools which help in fixing them. as Tom points out, it seems that some are simply a little too zealous in fixing them, maybe relying too heavily on the auto-fix feature in JOSM's validator, and should be looking at the data more thoroughly. Sorry was not 'blaming' duplicate nodes map directly. Unless that is it DOES highlight nodes which are at different elevations? In which case it should simply not be highlighting them in the first place? Then people would not be 'trying to correct them' ... If nodes have a different elevation then they perhaps should be identified differently if they need to be highlighted? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
On Sun, Jan 9, 2011 at 12:09 PM, Lester Caine wrote: > The original decision that there should be no duplicate nodes simply ignored > many of the arguments that there are very good reasons for needing them, > then tools like the duplicate nodes map ASSUME that the decision takes > priority rather than allowing 'duplicates' which are distinguished due to > their elevation? the duplicate nodes map doesn't assume that all duplicates are errors (http://matt.dev.openstreetmap.org/dupe_nodes/about.html#errors). it's simply a tool for finding them - because most of them are errors, - and it's nice to have tools which help in fixing them. as Tom points out, it seems that some are simply a little too zealous in fixing them, maybe relying too heavily on the auto-fix feature in JOSM's validator, and should be looking at the data more thoroughly. cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Tom Hughes wrote: On 09/01/11 10:34, Lester Caine wrote: Nathan Edgars II wrote: But why write routers for the one case thats > theoretically possible, instead of the millions that are not only > possible, but already in existance? I don't care how the routers are written. I care about people wrecking the data by merging dupes. And assuming that no nodes at different elevations but the same coordinates are allowed is just crass. Look people, this really is very simple and I have no idea why this thread has managed to go on so long... OpenStreetMap has, and always has had, a topological model. If two physical things are connected in real life then they should be connected in OSM by making them share a node. If they don't then that is a bug in the data that should be fixed. If two things which are not physically connected in the real world are sharing a node in the database then that is a bug in the data which should be fixed. Routing programs should rely on the topological data that we provide and not guess that things which are close are connected. People merging duplicate nodes should not do so blindly and should check what they are doing - in many cases that may mean having to do a physical survey or examine aerial imagery to verify the situation on the ground. Unfortunately the duplicate nodes map seems to encourage people to go round blindly merging which is why I don't particularly like it. It was noticeable that when I was using it and deliberately leaving some near me alone because I didn't know the real situation that other people would just come round and merge them anyway. Exactly ... Personally I will STILL use a new node if I need to even if there is an existing one with the same XY coordinates UNTIL I can establish if the elevation data needs to be different. Many of the comments as to why there is no need for the conflict since they can give examples of why the nodes on different ways do not need to overlap seem to miss the fact that splitting a way by another way such as an admin boundary needs to create a node which may well be defined on the admin boundary already, and the new node needs to be an a layer below or above that already defined. The original decision that there should be no duplicate nodes simply ignored many of the arguments that there are very good reasons for needing them, then tools like the duplicate nodes map ASSUME that the decision takes priority rather than allowing 'duplicates' which are distinguished due to their elevation? I'll be honest ... it's been a while since I had to worry, but I can remember having to edit things with the new node moved away from it's real location, and then move it back to where it should be. Deleting the other node at those bridges would have been equally wrong. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
On 09/01/11 10:34, Lester Caine wrote: Nathan Edgars II wrote: But why write routers for the one case thats > theoretically possible, instead of the millions that are not only > possible, but already in existance? I don't care how the routers are written. I care about people wrecking the data by merging dupes. And assuming that no nodes at different elevations but the same coordinates are allowed is just crass. Look people, this really is very simple and I have no idea why this thread has managed to go on so long... OpenStreetMap has, and always has had, a topological model. If two physical things are connected in real life then they should be connected in OSM by making them share a node. If they don't then that is a bug in the data that should be fixed. If two things which are not physically connected in the real world are sharing a node in the database then that is a bug in the data which should be fixed. Routing programs should rely on the topological data that we provide and not guess that things which are close are connected. People merging duplicate nodes should not do so blindly and should check what they are doing - in many cases that may mean having to do a physical survey or examine aerial imagery to verify the situation on the ground. Unfortunately the duplicate nodes map seems to encourage people to go round blindly merging which is why I don't particularly like it. It was noticeable that when I was using it and deliberately leaving some near me alone because I didn't know the real situation that other people would just come round and merge them anyway. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Nathan Edgars II wrote: But why write routers for the one case thats > theoretically possible, instead of the millions that are not only > possible, but already in existance? I don't care how the routers are written. I care about people wrecking the data by merging dupes. And assuming that no nodes at different elevations but the same coordinates are allowed is just crass. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Another possible scenario is a junction point between two elevated ramps, above a junction point between two surface roads. Since we live in a three-dimensional world, nodes with the same latitude and longitude, but different elevations, should not be considered to refer to the same point in three-dimensional space. ---Original Email--- Subject :Re: [OSM-talk] Postmortem analysys >From :mailto:da...@incanberra.com.au Date :Sat Jan 08 19:54:06 America/Chicago 2011 On Sat, 2011-01-08 at 20:27 -0500, Nathan Edgars II wrote: > On Sat, Jan 8, 2011 at 8:25 PM, David Murn wrote: > > On Sat, 2011-01-08 at 17:17 -0800, Nathan Edgars II wrote: > >> > >> If the name or ref is different on either side of the state line, then it > >> needs to be split in the middle. > > > > Thats fine, but does the state line need a node directly on-top of the > > road? Does the state line change as it crosses over the road? If not, > > then you dont need a node on the state line at the same point as the > > road, which means the duplicate node problem doesnt exist. > > That's why I specified a double-decker bridge: each deck gets split at the > line. I guess in theory, having a double decker bridge, directly over a state line is possible. But why write routers for the one case thats theoretically possible, instead of the millions that are not only possible, but already in existance? David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- John F. Eldredge -- j...@jfeldredge.com "Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Oops - meant to send this to the list. On Sat, Jan 8, 2011 at 8:54 PM, David Murn wrote: > On Sat, 2011-01-08 at 20:27 -0500, Nathan Edgars II wrote: >> That's why I specified a double-decker bridge: each deck gets split at the >> line. > > I guess in theory, having a double decker bridge, directly over a state > line is possible. It's not only possible, but exists: http://www.panynj.gov/bridges-tunnels/george-washington-bridge.html > But why write routers for the one case thats > theoretically possible, instead of the millions that are not only > possible, but already in existance? I don't care how the routers are written. I care about people wrecking the data by merging dupes. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
On Sat, Jan 8, 2011 at 8:54 PM, David Murn wrote: > But why write routers for the one case thats > theoretically possible, instead of the millions that are not only > possible, but already in existance? So your router doesn't tell people to jump off bridges. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
On Sat, 2011-01-08 at 20:27 -0500, Nathan Edgars II wrote: > On Sat, Jan 8, 2011 at 8:25 PM, David Murn wrote: > > On Sat, 2011-01-08 at 17:17 -0800, Nathan Edgars II wrote: > >> > >> If the name or ref is different on either side of the state line, then it > >> needs to be split in the middle. > > > > Thats fine, but does the state line need a node directly on-top of the > > road? Does the state line change as it crosses over the road? If not, > > then you dont need a node on the state line at the same point as the > > road, which means the duplicate node problem doesnt exist. > > That's why I specified a double-decker bridge: each deck gets split at the > line. I guess in theory, having a double decker bridge, directly over a state line is possible. But why write routers for the one case thats theoretically possible, instead of the millions that are not only possible, but already in existance? David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
On Sat, 2011-01-08 at 17:17 -0800, Nathan Edgars II wrote: > > If the name or ref is different on either side of the state line, then it > needs to be split in the middle. Thats fine, but does the state line need a node directly on-top of the road? Does the state line change as it crosses over the road? If not, then you dont need a node on the state line at the same point as the road, which means the duplicate node problem doesnt exist. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
On Sat, Jan 8, 2011 at 8:25 PM, David Murn wrote: > On Sat, 2011-01-08 at 17:17 -0800, Nathan Edgars II wrote: >> >> If the name or ref is different on either side of the state line, then it >> needs to be split in the middle. > > Thats fine, but does the state line need a node directly on-top of the > road? Does the state line change as it crosses over the road? If not, > then you dont need a node on the state line at the same point as the > road, which means the duplicate node problem doesnt exist. That's why I specified a double-decker bridge: each deck gets split at the line. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
David Murn wrote: > > On Fri, 2011-01-07 at 10:18 -0800, Nathan Edgars II wrote: >> >> Let those broken routers choke on real-world cases where nodes really are >> in >> the same place (double-decker bridge that crosses a state line, for >> example). I'll continue to map correctly. > > Just because you have ways crossing each other at a common point, that > doesnt mean they all have to have a node at the same point. When youre > putting a bridge over a creek, do you simply mark the start/end of the > bridge, or do you also put a node in the middle of the bridge above the > water? Just because a double-decker bridge crosses a border or river, > doesnt mean that each layer needs to have a node at exactly the same > point, unless youre either using low-accuracy GPS data, or delibrately > trying to make the map data harder to interpret by routers. > If the name or ref is different on either side of the state line, then it needs to be split in the middle. -- View this message in context: http://gis.638310.n2.nabble.com/Postmortem-analysys-tp5899422p5903544.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
On Fri, 2011-01-07 at 10:18 -0800, Nathan Edgars II wrote: > > Let those broken routers choke on real-world cases where nodes really are in > the same place (double-decker bridge that crosses a state line, for > example). I'll continue to map correctly. Just because you have ways crossing each other at a common point, that doesnt mean they all have to have a node at the same point. When youre putting a bridge over a creek, do you simply mark the start/end of the bridge, or do you also put a node in the middle of the bridge above the water? Just because a double-decker bridge crosses a border or river, doesnt mean that each layer needs to have a node at exactly the same point, unless youre either using low-accuracy GPS data, or delibrately trying to make the map data harder to interpret by routers. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
On Fri, Jan 7, 2011 at 8:27 PM, Nic Roets wrote: > After ungluing a node, move one of them just a little bit. If the road is straight at the would-be intersection, you should just delete the node, right? At the same time, having these nodes there isn't such a bad thing - at least it tests the routers for bugs like the one you described above. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Nathan Edgars II gmail.com> writes: > > > Nic Roets wrote: > > > > Mike, please don't blame the bot. > It's not the bot. It's the operator that did horrible stuff. And > bot-operator-enablers who defended their actions. The people who might have written an intelligent bot (only joining roads to other roads, only joining them on county boundaries, understanding differences of level) have been too scared to do so, leaving the door open for stupid ones. > Let those broken routers choke on real-world cases where nodes really are in > the same place (double-decker bridge that crosses a state line, for > example). I'll continue to map correctly. Yes, absolutely; tweaking the mapped network to work round bugs in routers is like tagging for the renderer. -- Andrew ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
I would suggest any (!) automatically dupe node analysis tool to respect every possible tag present at two nodes. Even two nodes describing two doctors in one building with different opening hours are sometimes wanted to be at the same coordinates, there is nothing describing anything like level, elevation or layer; and nothing needed. Collapsing these will produce wrong data as the opening hours of the one is connected to the other without intent. At least the user pointed to some issue of that kind should be advised to be carefully - more carfully than at nodes without tags on the same location. regards Peter Am 08.01.2011 10:19, schrieb Ed Avis: Vincent Pottier gmail.com> writes: QA tools like Keepright make it feasible to monitor and maintain large areas in a fully correct topology. But Keepright is bugged on that point. We have had to revert about 300 changesets from someone who glued nodes with different ele values on survey marks. Keepright (and other) ignore the ele tag. I believe keepright does take note of the layer tag to see when two ways are not intended to meet, but I guess it doesn't know about ele. (I didn't know about that tag either - not that I am any kind of OSM expert - just saying that it is little used in some countries where the data isn't available.) I've sent a message to Harald K., the keepright maintainer, to ask if this can be fixed. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Vincent Pottier gmail.com> writes: >> QA tools like Keepright make it feasible to monitor and maintain >>large areas in a fully correct topology. > >But Keepright is bugged on that point. >We have had to revert about 300 changesets from someone who glued nodes >with different ele values on survey marks. Keepright (and other) ignore >the ele tag. I believe keepright does take note of the layer tag to see when two ways are not intended to meet, but I guess it doesn't know about ele. (I didn't know about that tag either - not that I am any kind of OSM expert - just saying that it is little used in some countries where the data isn't available.) I've sent a message to Harald K., the keepright maintainer, to ask if this can be fixed. -- Ed Avis ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Le 08/01/2011 02:34, Mike N. a écrit : I'm not familiar with how survey marks are used - are there multiple marks at the same lat/lon but different ele? Not always but very often, the French IGN made several geodesic points on the same object to alow multiple mesurement.[1] The typical case is the cross among a bell tower : one point is on the top or center of the cross, one other is on the bottom of the cross. So they exactyl have the same lat/lon but a dirrerent elevation [2] A mistake came also after the creation of water towers. On the IGN's survey marks, they are indications on the object carrying it: church, chemney, water tower... A little tool was made to find it.[3] A lot of objects have been created from those indications, mainly water tower. But those objects had no elevation tag for it was unknonw. Keepright (and other) indicate those point has dupes. And several have been merged. [4] Those points, in OpenStreetMap, are very precious. They are used for cheking the quality of aeral imagery and other stuff... [1] http://geodesie.openstreetmap.fr/cgi-bin/index.py?zoom=12&lat=48.05932&lon=1.91779&layers=B0T&ch=1100,1200 [2] http://www.openstreetmap.org/browse/node/670053466 http://www.openstreetmap.org/browse/node/670053469 [3] http://osmose.openstreetmap.fr/map/cgi-bin/index.py?zoom=10&lat=48.09885&lon=2.04795&layers=B00T&item=7010 [4] http://www.openstreetmap.org/browse/node/670053455 http://www.openstreetmap.org/browse/node/527901535 -- FrViPofm ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
After ungluing a node, move one of them just a little bit. (Unless you used a DGPS with a 10cm resolution and found that the centerlines are in fact on top of each other). If you leave them on top of each other, it's going to waste someone's time later on (either after a bot edit, a keepright warning, a routing error or a user editing the area who is completely oblivious to the possibility that two nodes can be on top of each other). Agreed - my preferred method is just to delete intersection nodes and realign if necessary. That only fails if 2 ways also join at the intersection node. We have had to revert about 300 changesets from someone who glued nodes with different ele values on survey marks. I'm not familiar with how survey marks are used - are there multiple marks at the same lat/lon but different ele? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
On Fri, Jan 7, 2011 at 11:49 PM, Mike N. wrote: >> Mike, please don't blame the bot. Ungluing a node an just leaving it >> there, is really looking for trouble. Some routing engine(s) glue >> nodes together that are less than a few centimeters from each other. >> Now you may want to complain that those routing engine(s) are buggy, >> but that "bug" has historically made things easier rather than more >> difficult. And going forward, I expect it to continue to be a >> "feature" rather than a bug. > > Consider me firmly in the "it's a bug" camp. Routers in general work with > data from different sources; but it's a bug in OSM to have an intended > connection only be close but not connected.There's no minimum node > distance for disconnected nodes - just best practices to minimize database > clutter from dupe nodes. QA tools like Keepright make it feasible to > monitor and maintain large areas in a fully correct topology. > > Do routing engines glue nodes from different layers? Yes, provided they are close enough (for the engine(s) in question). > Do they automatically > connect crossing ways on the same layer? Only in the rare case where both crossing ways contain nodes at the crossing point. (for the engine(s) in question). Look, I'm saying that I do my part fix things that may cause problems somewhere in the software stack. For example, I discovered that the Appalachian trail was at some point the largest object in the DB. Potlach and several other pieces of software would either bomb out or take ages to respond. So I messaged the last editor and he agreed that many of the nodes are redundant. So I deleted those nodes. After ungluing a node, move one of them just a little bit. (Unless you used a DGPS with a 10cm resolution and found that the centerlines are in fact on top of each other). If you leave them on top of each other, it's going to waste someone's time later on (either after a bot edit, a keepright warning, a routing error or a user editing the area who is completely oblivious to the possibility that two nodes can be on top of each other). A very simple way of reducing the problem inside the router will be to move nodes by small random amounts, but I have more urgent bugs and feature requests. > Either modification would change > the calculated route. > > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Mike N. wrote: Do routing engines glue nodes from different layers? Do they automatically connect crossing ways on the same layer? Either modification would change the calculated route. I just love it when my tomtom gets confused when there is one of the quite regular errors in a route and I go the physical path while it is telling me to 'turn left' off the bridge and straight onto the motorway below. Even paid for data has many holes in it :( Elevation is a critical element and HAS to be respected. two nodes may well be at the same coordinates, but they are NOT necessarily the same point -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Le 07/01/2011 22:49, Mike N. a écrit : Consider me firmly in the "it's a bug" camp. Routers in general work with data from different sources; but it's a bug in OSM to have an intended connection only be close but not connected.There's no minimum node distance for disconnected nodes - just best practices to minimize database clutter from dupe nodes. There is no distance for disconnected nodes if they have different ele or layer values. QA tools like Keepright make it feasible to monitor and maintain large areas in a fully correct topology. But Keepright is bugged on that point. We have had to revert about 300 changesets from someone who glued nodes with different ele values on survey marks. Keepright (and other) ignore the ele tag. -- FrViPofm ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Mike, please don't blame the bot. Ungluing a node an just leaving it there, is really looking for trouble. Some routing engine(s) glue nodes together that are less than a few centimeters from each other. Now you may want to complain that those routing engine(s) are buggy, but that "bug" has historically made things easier rather than more difficult. And going forward, I expect it to continue to be a "feature" rather than a bug. Consider me firmly in the "it's a bug" camp. Routers in general work with data from different sources; but it's a bug in OSM to have an intended connection only be close but not connected.There's no minimum node distance for disconnected nodes - just best practices to minimize database clutter from dupe nodes. QA tools like Keepright make it feasible to monitor and maintain large areas in a fully correct topology. Do routing engines glue nodes from different layers? Do they automatically connect crossing ways on the same layer? Either modification would change the calculated route. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Am 07.01.2011 17:12, schrieb Nic Roets: On Fri, Jan 7, 2011 at 4:39 PM, Mike N. wrote: Recently I encountered a CSI-style mystery. Why was the Skobbler lady (OSM Nav based) telling people to go jump off of so many bridges? An inspection showed that the bridges were joined to the interstate highway below, but many interchanges otherwise had very high quality edits, with attention to many details. So how did the people who made such skilled edits overlook false intersections? It turns out that they didn't. A history view shows the dreaded "Removing duplicate nodes" in the change list. The original edit just used JOSM's un(G)lue node command, leaving the dupe nodes in place. A perfectly valid technique until the attack of the duplicate node bots. Mike, please don't blame the bot. Ungluing a node an just leaving it there, is really looking for trouble. Some routing engine(s) glue nodes together that are less than a few centimeters from each other. Now you may want to complain that those routing engine(s) are buggy, but that "bug" has historically made things easier rather than more difficult. And going forward, I expect it to continue to be a "feature" rather than a bug. -1 I (partly) disagree here. I agree that it's kind of feature to collapse nodes in routing engines to save complexity of the routing graph, but Mike mentioned, that with that implementation of this "feature" a change in the topology occurs: there are connections not present in the original data before the glueing routine. THAT IMHO is a bug, not a feature. regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
Nic Roets wrote: > > Mike, please don't blame the bot. It's not the bot. It's the operator that did horrible stuff. And bot-operator-enablers who defended their actions. Nic Roets wrote: > Ungluing a node an just leaving it > there, is really looking for trouble. Some routing engine(s) glue > nodes together that are less than a few centimeters from each other. > Now you may want to complain that those routing engine(s) are buggy, > but that "bug" has historically made things easier rather than more > difficult. And going forward, I expect it to continue to be a > "feature" rather than a bug. Let those broken routers choke on real-world cases where nodes really are in the same place (double-decker bridge that crosses a state line, for example). I'll continue to map correctly. -- View this message in context: http://gis.638310.n2.nabble.com/Postmortem-analysys-tp5899422p5900287.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Postmortem analysys
On Fri, Jan 7, 2011 at 4:39 PM, Mike N. wrote: > Recently I encountered a CSI-style mystery. Why was the Skobbler lady (OSM > Nav based) telling people to go jump off of so many bridges? An inspection > showed that the bridges were joined to the interstate highway below, but > many interchanges otherwise had very high quality edits, with attention to > many details. So how did the people who made such skilled edits overlook > false intersections? It turns out that they didn't. A history view shows > the dreaded "Removing duplicate nodes" in the change list. The original > edit just used JOSM's un(G)lue node command, leaving the dupe nodes in > place. A perfectly valid technique until the attack of the duplicate node > bots. Mike, please don't blame the bot. Ungluing a node an just leaving it there, is really looking for trouble. Some routing engine(s) glue nodes together that are less than a few centimeters from each other. Now you may want to complain that those routing engine(s) are buggy, but that "bug" has historically made things easier rather than more difficult. And going forward, I expect it to continue to be a "feature" rather than a bug. > > Now this is all past history - I think most of the mass and uninformed > duplicate node work in the US has stopped since last year. But, like the > grumpy old man who runs outside and yells at the neighborhood kids who play > in his yard, you can bet that every time I hear the whir and clickety-clack > of anything that sounds like an OSM bot, I'll make sure that they've done > due diligence rather than just relying on only the changeset comment. But > quality bot edits are still welcome! > > P.S. Don't get me started on how the dupe node bots made a 3 minute county > line road fixup into a 30 minute nightmare. > > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Postmortem analysys
Recently I encountered a CSI-style mystery. Why was the Skobbler lady (OSM Nav based) telling people to go jump off of so many bridges? An inspection showed that the bridges were joined to the interstate highway below, but many interchanges otherwise had very high quality edits, with attention to many details. So how did the people who made such skilled edits overlook false intersections? It turns out that they didn't. A history view shows the dreaded "Removing duplicate nodes" in the change list. The original edit just used JOSM's un(G)lue node command, leaving the dupe nodes in place. A perfectly valid technique until the attack of the duplicate node bots. Now this is all past history - I think most of the mass and uninformed duplicate node work in the US has stopped since last year. But, like the grumpy old man who runs outside and yells at the neighborhood kids who play in his yard, you can bet that every time I hear the whir and clickety-clack of anything that sounds like an OSM bot, I'll make sure that they've done due diligence rather than just relying on only the changeset comment. But quality bot edits are still welcome! P.S. Don't get me started on how the dupe node bots made a 3 minute county line road fixup into a 30 minute nightmare. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
