[OSM-dev] shp2osm.pl
Anthony
osm at inbox.org
Wed Sep 30 02:01:34 BST 2009
On Tue, Sep 29, 2009 at 8:34 PM, Ian Dees <ian.dees at gmail.com> wrote:
> On Tue, Sep 29, 2009 at 6:58 PM, Anthony <osm at inbox.org> wrote:
> Can we assume the shared ways use shared nodes? I was planning on making
> that assumption, because I believe it's true for the particular data I'm
> trying to import. Without that assumption, it's probably too much work for
> the time I have.
>
> No. In most cases the ways do not share nodes. Almost all of the time, the
> overlapping ways share node locations.
>
Okay, I was imprecise (a terrible thing when dealing with this topic, so my
apologies).
Before I dealt with those other problems I was going to be to go through my
data and merge any nodes with shared locations into shared nodes. I'll
probably do this while importing the data into a database, and it should be
very easy. I need the database because I want to be able to extract
sections of the data (individual neighborhoods at a time), and I've
currently got a half gig shapefile (which converts to a 1.7 gig .osm file),
which seems to have the polygons in fairly random order.
I'm a little worried there might be situations like this, though:
w--x
| |
a--b |
| | |
c--d |
| |
y--z
With WY overlapping BD, but not sharing any nodes. If you think you can
attack that situation, I'd be happy to help.
In any case, I have to worry about converting the multipolygons from the
>> shapefile I have first. I'm pretty sure there are some, in the standard
>> "holes go clockwise" format, and shp2osm doesn't handle that as far as I can
>> tell.
>>
>
> My Java version of shp-to-osm handled this automatically. It appears to me
> that the shapefile format follows the same model we do: clockwise for outer
> rings and anti-clockwise for inner rings (e.g. "holes").
>
I should probably check out the java version. Does this use the old 0.4
method, or the new multipolygon relations?
I guess using multipolygon relations won't be too bad. I just leave the
tags off all but one outer way (whatever one has the biggest area?), and
then reference them in a relation (calculating the area to determine
clockwise/anti-clockwise).
Ugh, it sounds so easy until you get down to the nitty gritty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20090929/8ad407bd/attachment.html>
More information about the dev
mailing list