Hi Toby,<br><div class="gmail_extra"><br><div class="gmail_quote">On 20 November 2012 16:30, Toby Murray <span dir="ltr"><<a href="mailto:toby.murray@gmail.com" target="_blank">toby.murray@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have started playing with this in a branch:<br>
<a href="https://github.com/ToeBee/osmosis/tree/invalid_geometry" target="_blank">https://github.com/ToeBee/osmosis/tree/invalid_geometry</a><br>
<br>
So far I managed to add a new command line option "keepInvalidWays" to<br>
the write-pgsql(-dump) tasks. It defaults to false so that current<br>
functionality of dropping zero and single node ways is preserved.<br></blockquote><div><br>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.<br>
<br>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.<br>
<br>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.<br><br>Thoughts?  Either way, the keepInvalidWays should solve most current issues, so is a higher priority.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I think it should be possible to add it to the diff processing as well<br>
to keep invalid ways out of a replicated database. I likely won't get<br>
a chance to work on it much more before next week because of<br>
Thanksgiving travel plans but I may try to reimport my database with<br>
this option enabled while I am out of town to see exactly what effects<br>
it has.<br></blockquote><div><br>Sounds great.  I'm keen to ensure that initial import and replication are consistent, even if they're not today.<br><br>Brett<br><br></div></div></div>