On Fri, Nov 21, 2014 at 11:57:47AM -0800, Paul Norman wrote:
On 11/21/2014 10:09 AM, Stefan Baebler wrote:
From the bugfix perspective it should probably be one more step of merging
(eg MergeWays()) after two prior merges (mergePoints() and
mergeWayPoints()).
Yes - and this shouldn't be too
On 11/24/2014 9:29 AM, Jochen Topf wrote:
But in a more complex case with more nodes and maybe some other lines
involved, we probably want two multipolygons which share a way D-C (and have
separate ways D-A-B-C and D-E-F-C, respectively), don't we? But then we have
to split up those linestrings.
Hi!
While preparing a dataset for a community import (
https://wiki.openstreetmap.org/wiki/Slovenia_Landcover_Import_-_RABA-KGZ )
we ran into 2 kinds of related problems that originate from Shapefile's
different representation of polygons:
a) duplicated ways: when no tags are present on two
On 11/21/2014 8:58 AM, Stefan Baebler wrote:
Is ogr2osm being actively maintained?
Yes - but I don't have time to add new features like #28. I'd welcome a
PR doing so, but have no ETA of when I would get to it.
___
dev mailing list
Paul, thanks for fast response! I perfectly understand you, it's normal for
opensource :)
Imports from shapefiles are nothing new and have been going on with various
tools for many years. I wanted to discuss with commuity whether this
situation is anomaly or something tolerable as at least two
On 11/21/2014 10:09 AM, Stefan Baebler wrote:
From the bugfix perspective it should probably be one more step of
merging (eg MergeWays()) after two prior merges (mergePoints()
and mergeWayPoints()).
Yes - and this shouldn't be too computationally expensive, as there
aren't that many ways, at
6 matches
Mail list logo
