[osmosis-dev] Single node ways

[Brett Henderson]

Hi Toby,

On 20 November 2012 16:30, Toby Murray <toby.murray at gmail.com> wrote:

> I have started playing with this in a branch:
> https://github.com/ToeBee/osmosis/tree/invalid_geometry
>
> So far I managed to add a new command line option "keepInvalidWays" to
> the write-pgsql(-dump) tasks. It defaults to false so that current
> functionality of dropping zero and single node ways is preserved.
>

I'd actually be happier if the default position is to include all data
regardless of whether it is accurate or not.  I feel that is the behaviour
of least surprise, even if it is different to today.  The pgsnapshot schema
is intended to be a complete and accurate representation of OSM data, so
any deviation from that should be explicitly selected by the user.

Would it make sense to separate the dropping of ways from the dropping of
linestrings?  Perhaps two options like keepInvalidWays and
keepInvalidLinestrings?  If keepInvalidWays=true, but
keepInvalidLinestrings=false then the linestring column could be set to
NULL if the way doesn't contain two or more nodes.

The reason I say this is because there may be cases where you want an
accurate copy of OSM data, and only include the linestring as a means of
performing geo-spatial queries against that data.

Thoughts?  Either way, the keepInvalidWays should solve most current
issues, so is a higher priority.


> I think it should be possible to add it to the diff processing as well
> to keep invalid ways out of a replicated database. I likely won't get
> a chance to work on it much more before next week because of
> Thanksgiving travel plans but I may try to reimport my database with
> this option enabled while I am out of town to see exactly what effects
> it has.
>

Sounds great.  I'm keen to ensure that initial import and replication are
consistent, even if they're not today.

Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmosis-dev/attachments/20121123/ac01e372/attachment.html>