Thanks Dermot Is correcting it inside OSM the only way to deal with this kind of data? If so, i'm thinking of compiling a list of all the ways that do not comply, and then posting them somewhere so that we can all pick them off one by one. There are a lot in Australia alone (using the aussie export to get my testing done). I have a feeling that anyone using Sql Server Spatial will have these issues.
Regards, Brendan On Thu, Feb 19, 2009 at 12:01 AM, Dermot McNally <[email protected]> wrote: > Hi Brendan, > > I've just looked at the piece of coastline in question and found two > errors in it (both now fixed): > > * There was a duplicate node > > * At a different place, the coastline overlapped itself. > > I can see how these (particularly the overlap) could be confusing to > the DB. It may be worth trying it again with the new data. > > Dermot > > 2009/2/18 brendan barrett <[email protected]>: >> Hi >> >> I've just signed up to the dev mailing list, and hopefully i'll catch >> up by reading the archives. For now though I have a question and >> please don't follow up with insults if you see the names Microsoft or >> SQL Server :P >> >> I'm trying to render coastlines in an application that I am building. >> The concept is simple: find the lines, and join them end on end until >> you get an area. Now my problem is with OGC standards. I'm using Sql >> Server 2008 *ducks for cover* and more specifically the new Sql Server >> Spatial types (Geography and Geometry). Sql Server 2008 seems to be >> pretty strict with OGC standards, and I am but a beginner when it >> comes to OGC standards. >> >> The problem i'm having is with some coastlines in OSM that double back >> on themselves. Like this one: >> >> This way http://www.openstreetmap.org/browse/way/13858554 doubles back >> on itself with this node >> http://www.openstreetmap.org/browse/node/130020792 having the same >> latitude as this consecutive node >> http://www.openstreetmap.org/browse/node/130020793. >> >> I think this is the reason for the way being invalid in Sql Server's >> eyes. The MS folks have included the MakeValid() function which >> "corrects" the way to comply with OGC standards, but this changes the >> latitude and longitude of every point in the line ever so slightly, >> and that's not desirable if you are matching ways end on end. I can >> use the Node Ids to match them, but the bigger issue is that my data >> is "invalid" and I can't use other spatial methods on it. >> >> I have 4 questions: >> 1. Is this doubling back really an OGC restriction? It makes sense >> that these ways don't double back because it doesn't serve any purpose >> for a coastline (or for any line, you would expect even a path that >> doubles back to be at least some distance apart, or simply labeled two >> way). >> 2. If this is a problem, is it something that will be fixed in the >> editors / the API? >> 3. Is there anyone else here with experience with SQL Server 2008 >> Spatial and OSM that might have some tips on dealing with all these >> ways? >> 4. Does PostGIS have these types of issues? >> >> I'm thinking that the only way for me to deal with this is to correct >> the data in OSM (if it's clearly incorrect) or in my database once >> imported (if there's no other solution). >> >> Thoughts? >> >> _______________________________________________ >> dev mailing list >> [email protected] >> http://lists.openstreetmap.org/listinfo/dev >> > > > > -- > -------------------------------------- > Iren sind menschlich > _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
