Well I looked at this tonight. It looks like postgis is perfectly happy creating a linestring for a single node way. However it is not considered valid. So doing a st_isvalid() on the resulting linestring returns false. I am not sure what all the implications of this are however it looks like it is something that needs to be handled regardless. I have over 200 of them in my database right now. The few I looked at are ways with several nodes in them that are all at the same location.
I also noticed that not only are there ways with only one node in them... there are also ways with zero nodes in them! These are also being dropped right now. Completely removing the object count check successfully imports the zero node ways as well. Interestingly, the linestring is actually considered valid. However there is a function st_isEmpty() which identifies it as an empty geometry. So unless we want to do stricter checking to ensure no invalid linestrings make it in, I propose just removing the check for node count and letting all ways into the database, invalid/empty linestrings and all. Is there any chance that these behaviors will be different on different versions of postgres/postgis? I'm using 9.1/2.0.1 Thoughts? Toby On Thu, Nov 8, 2012 at 10:58 PM, Brett Henderson <[email protected]> wrote: > Hi Toby, > > On 5 November 2012 16:25, Toby Murray <[email protected]> wrote: >> >> It seems osmosis intentionally drops ways with only one node in them >> when importing[1]. From another thread[2] on this mailing list, I >> understand this is because postgis does not handle such things very >> well. However, when consuming diffs, single node ways do make it into >> the database. In some situations this seems to cause errors when >> querying the data, but not every time. >> >> So first of all, there is an inconsistency between how the load >> process and the diff process handles these ways. But is there any >> other way to handle this besides dropping them completely? There are a >> couple of uses of the pgnsapshot schema that assume that it is a >> lossless way of storing OSM data and as far as I know, it is - except >> for this one exception. While single node ways are definitely a bug, >> they happen with unfortunate regularity, mostly due to bugs in editing >> software. Would it be acceptable to add in a phantom node 3cm away >> from the first oneor something, just while building the geometry? I >> think that happens in SQL while applying diffs which would make it >> more difficult since you don't actually want to insert nodes that >> don't exist... Thoughts? >> >> [1] >> https://github.com/ToeBee/osmosis/blob/master/pgsnapshot/src/main/java/org/openstreetmap/osmosis/pgsnapshot/v0_6/impl/CopyFilesetBuilder.java#L186 >> [2] >> http://gis.19327.n5.nabble.com/osmosis-dev-one-node-ways-td5338301.html > > > Dropping the single node ways is messy. A phantom node in the generated > linestring might be a better workaround. If nobody has any better ideas I'm > open to it being changed. Are you able to create a patch? > > Brett > _______________________________________________ osmosis-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/osmosis-dev
