On 14 Nov 2012, at 11:48, Paweł Paprota <[email protected]> wrote:
> On 11/14/2012 12:33 PM, Brett Henderson wrote: > > >> It sounds good to me. Osmosis typically tries to maintain data accuracy >> with no surprises, so I'm not particularly happy with the current >> situation of dropping ways even if they are invalid. >> >> Jochen Topf was the one who originally introduced the checks in >> WayGeometryBuilder to ensure a Way contained at least two nodes. He >> might have some thoughts on whether we can remove the checks. Perhaps >> it was simply introduced to avoid the additional overheads of having to >> do st_isvalid() checks? >> > > Based on my experience with processing geometry for OSM objects I'd strongly > discourage having any invalid geometries in the database. This leads to very > unpleasant surprises with ST_Union, ST_Intersection and other spatial > functions. Upgrading the GEOS library (which PostGIS uses) helps a bit but > still many operations can behave very strangely and after hours/days of > debugging you find yourself hitting the "invalid geometry" wall. > > Whether Osmosis should be responsible for maintaining valid geometries is > kind of a different question I think - depends on policy. But whatever you > decide, it needs to be communicated front and center in documentation what > geometry is created. The problem is that if you are using Osmosis to shunt the data into a database that you use to find and highlight these invalid geometries for the community to go and fix in the source data. I think that Osmosis could have a filter to drop invalid data, or even the inverse of only outputting the invalid data. Shaun _______________________________________________ osmosis-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/osmosis-dev
