[OSM-dev] shp2osm.pl

Ian Dees ian.dees at gmail.com
Wed Sep 30 02:12:03 BST 2009

On Tue, Sep 29, 2009 at 8:01 PM, Anthony <osm at inbox.org> wrote:

> 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 this case, I don't consider way WY to be overlapping with BD. I would
only consider them overlapping if nodes B and D are part of the way WXYZ.

>  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 rewrote it a while ago to use multipolygon relations when ways are >2000
nodes and when the shapefile contains a multipolygon.


> 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).

I currently put the tags on the multipolygon relation, but yes, the
polygon's tags should end up on the outer ways according to the wiki page.

> Ugh, it sounds so easy until you get down to the nitty gritty.

Yep :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20090929/30af1f50/attachment.html>

More information about the dev mailing list