[osmosis-dev] Invalid ways, now with code

[Toby Murray]

On Wed, Dec 12, 2012 at 5:22 AM, Paweł Paprota <ppawel at fastmail.fm> wrote:
> Hi Toby,
>
>>
>>
>> Anyway, thoughts? My changes are on github in the invalid_geometry branch:
>> https://github.com/ToeBee/osmosis
>>
>> And a diff of all my changes:
>> https://github.com/ToeBee/osmosis/compare/master...invalid_geometry
>>
>
> What about other situations where a way is invalid? For example, this
> results in 'f':
>
> SELECT ST_IsValid('LINESTRING(1 1, 1 1, 1 1, 1 1, 1 1)'::geometry)

This was touched on in the previous thread a little. The problem is
that there is no direct interaction with the database at this level.
When doing an import, no connection to the database even exists.
Everything goes to a dump file and is then loaded in via a COPY
command. So I can't just call ST_IsValid. Furthermore, I don't see a
way of checking for geometry validity in java. I could maybe do a few
basic checks based on node order and location but I suspect that if I
start touching  nodes at all, there is going to be a huge performance
hit on a planet import.

Also, out of the 3,455 ways with invalid geometries currently in my
database, 3,157 of them are single node ways. So just this simple node
count check eliminates over 90% of invalid geometries. Given the
challenges and costs of doing more exhaustive checking, this seems
like a decent compromise.

My personal goal here is actually to have a database *with* these
invalid ways in it which is currently not possible. Because objections
were raised about how these ways can affect some spatial queries, I am
trying to reduce the impact of them on people who do care about such
things. The new option on the replication task is a big step forward
in this case. I don't think it is currently possible to keep *all*
invalid ways out of the database during an import. If this is really a
requirement, it will need to be done with a query after the database
has been populated.

Toby