Re: [OSM-talk] multipolygon inners that aren't inside.
John Harvey (j...@johnharveyphoto.com) wrote: It sure would be nice if users couldn't submit bad data. Incorrect data (wrong street name) takes a human to spot, but bad topology (doesn't conform to the rules and a computer can verify conformance) shouldn't be possible to submit. For instance look at this relation: http://www.openstreetmap.org/browse/relation/542980 Two ways are marked as inners but nothing is inside anything else. The problem is these kinds of errors present a barrier to entry for anyone using the OSM data - if you try to write a by the books renderer for this area you get a spill. To render it correctly you have to test ways marked the inner are actually inside something marked outside. Mapnik and Osmarender render this area correctly so I believe they have inside/outside tests. NoName doesn't render the outers and doesn't spill - I believe it detects the error and handles it in a different way. Maplint doesn't appear to catch this error. If the code in those three renderers (which catch this error and handle it two different ways) was instead in the submission engine the OSM data would be better for it. A few other examples of the same problem: 269371 169869 532010 532014 533606 940715 111577 361745 107964 222633 554456 541196 302153 188115 (when an inner and outer share an edge point you get the same problem). John FWIW, if you process the OSM data with mkgmap you will get warnings (and permalinks) for multipolygon errors like these. It's a handy debugging tool. -- Charlie ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] multipolygon inners that aren't inside.
It sure would be nice if users couldn't submit bad data. Incorrect data (wrong street name) takes a human to spot, but bad topology (doesn't conform to the rules and a computer can verify conformance) shouldn't be possible to submit. For instance look at this relation: http://www.openstreetmap.org/browse/relation/542980 Two ways are marked as inners but nothing is inside anything else. The problem is these kinds of errors present a barrier to entry for anyone using the OSM data - if you try to write a by the books renderer for this area you get a spill. To render it correctly you have to test ways marked the inner are actually inside something marked outside. Mapnik and Osmarender render this area correctly so I believe they have inside/outside tests. NoName doesn't render the outers and doesn't spill - I believe it detects the error and handles it in a different way. Maplint doesn't appear to catch this error. If the code in those three renderers (which catch this error and handle it two different ways) was instead in the submission engine the OSM data would be better for it. A few other examples of the same problem: 269371 169869 532010 532014 533606 940715 111577 361745 107964 222633 554456 541196 302153 188115 (when an inner and outer share an edge point you get the same problem). John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon inners that aren't inside.
On Mon, Jul 12, 2010 at 2:27 PM, John Harvey j...@johnharveyphoto.comwrote: It sure would be nice if users couldn't submit bad data. Incorrect data (wrong street name) takes a human to spot, but bad topology (doesn't conform to the rules and a computer can verify conformance) shouldn't be possible to submit. For instance look at this relation: http://www.openstreetmap.org/browse/relation/542980 Two ways are marked as inners but nothing is inside anything else. The problem is these kinds of errors present a barrier to entry for anyone using the OSM data - if you try to write a by the books renderer for this area you get a spill. To render it correctly you have to test ways marked the inner are actually inside something marked outside. For better or worse there is no incorrect data. If your parser/renderer can't handle data like this, then you should probably filter it out. You'll have a very hard time convincing anyone to add the data integrity checks that would be required on the API for this sort of thing. Maybe you could write a bot that messages the owner of the relation when it finds incorrect topology? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon inners that aren't inside.
John, John Harvey wrote: Two ways are marked as inners but nothing is inside anything else. The problem is these kinds of errors present a barrier to entry for anyone using the OSM data - if you try to write a by the books renderer for this area you get a spill. A by the books renderer should definitely ignore inner/outer roles and just find things out by itself. To render it correctly you have to test ways marked the inner are actually inside something marked outside. Yes. If the code in those three renderers (which catch this error and handle it two different ways) was instead in the submission engine the OSM data would be better for it. Too difficult - too much logic in the submission engine. Imagine, every time someone touches any of the nodes that's part of any polygon ring, the full polygon validity check would have to kick in. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] multipolygon inners that aren't inside.
Hi, Ian Dees wrote: Maybe you could write a bot that messages the owner of the relation when it finds incorrect topology? Note that the topology might have been correct when the relation was created, and only became problematic by someone else moving a node or so. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
