[osmosis-dev] Invalid ways, now with code

[Paweł Paprota]

Hi Toby,

On 12/14/2012 03:40 AM, Toby Murray wrote:

>>
>> Sure but in this case I would suggest naming this option
>> differently because setting keepInvalidWays to false implies that
>> there will be no invalid ways in the database which may not be true
>> with the current implementation of this option.
>
> Well technically there is a difference between way validity and
> linestring validity :)
>

Yeah, I am/was using the term way/linestring interchangeably... In any 
case my opinion is that naming this option keepInvalidWays is a bit of a 
stretch since it can lead to dangerous assumptions like assuming that 
all way geometry (linestrings) are valid which is not correct.

>
> Yes, it would in theory be possible with the JTS library. Do you
> have any idea how efficient this check is? If it takes 1 ms to check
> for linestring validity then it will add 28 hours to a planet import
> at which point it would be faster to do a "DELETE where not
> ST_IsValid()" query after the data is loaded. But I guess I might
> play around with it and see.
>

I have not used JTS directly so I am not sure about performance. My 
guess from experience with PostGIS would be that it won't matter too 
much since I have not encountered ST_IsValid/ST_MakeValid calls that 
last longer than a few milliseconds. Validity code in JTS should be 
pretty much the same in JTS as in GEOS/PostGIS but the only way to 
really find out is to do a real benchmark...

> The other problem is that this method can't be used in replication
> mode since the linestring is built in SQL. But checking node count
> still works.
>

During replication it would be possible to simply use ST_IsValid from 
PostGIS but then the question is what to do with ways that become 
invalid in some new replicated version - remove them altogether?

> I still think the code I have right now is useful. The biggest plus
> is that it creates consistency between what happens during import
> and what happens during diff application. And it takes care of a
> vast majority of the problem cases at the cost of (more or less) one
> if statement.
>

Sure, I'm not saying it's not useful, I just have a small problem with 
naming since invalid geometry gave me *a lot* of headaches one time and 
I would prefer to have it very clearly documented.

Ultimately it is up to you and/or Brett as the maintainer to decide how 
to name it, I can always add some note to wiki documentation about this 
so all in all it's not a big deal.

Paweł