shp-to-osm 0.7

[yellowbkpk]

I just uploaded shp-to-osm 0.7, a Java tool to convert shapefiles to OSM format.

This version adds two important features:
- "glomming": the ability to connect ways based on a key/value pair
- tags for multipolygon relations have been moved from the relation to the outer ways (fixing a bug with the -t option)

Download it here:
http://redmine.yellowbkpk.com/projects/list_files/geo

File bugs/feature requests here:
http://redmine.yellowbkpk.com/projects/geo/issues/new

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[acrosscanadatrails]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Cool thanks :)

Great Job!

Sam

On Tue, Nov 3, 2009 at 8:38 PM, Ian Dees <ian.dees@...> wrote:

I just uploaded shp-to-osm 0.7, a Java tool to convert shapefiles to OSM format.

This version adds two important features:
- "glomming": the ability to connect ways based on a key/value pair
- tags for multipolygon relations have been moved from the relation to the outer ways (fixing a bug with the -t option)

Download it here:
http://redmine.yellowbkpk.com/projects/list_files/geo

File bugs/feature requests here:
http://redmine.yellowbkpk.com/projects/geo/issues/new

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Frederik Ramm]

Hi,

Ian Dees wrote:
> - tags for multipolygon relations have been moved from the relation to
> the outer ways (fixing a bug with the -t option)

Why that? I think that having tags on the outer way is a legacy thing;
when I create new multipolygons, I leave the outer way untagged and put
the tags on the relation only.

This becomes especially important if the outer ring consist of multiple
ways.

Bye
Frederik

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[acrosscanadatrails]

Re: tags on the relation

That might be possable, but its sorcery for shp-to-osm, as (i dont
think it can be done with the 'rules.txt' file?
As the rules simply puts tags on node-way-area.
(Shp2osm could maybe)?

However, i think that i might wrong in my crazy assumptions. :)

 Because the tags already DO/DID get put on the relation. ... And
having it on the 'outer'? .... Dang, your right.

Because this is NOT a polygon, but a 'multi-polygon' where it has that
extra attribute of a 'dohnut whole'

Just like we dont tag the nodes of a way, nor the nodes of a polygon.
& tagging a closed way, automatically becomes a polygon.
-it seems that a relation is the natural progression.

Although a multi-polygon cant be selected, as it would select whatever
is on that 'mainland' instead, so to select the 'multi-polygon' you
would need to click directly on the water. (if that makes sence)

What i think would be better is to not use multi-polygons alltogether. :)

Since that 'island' in the middle, could be anything. A 'reef' or
'sand' or 'islet' or 'wood' or 'grass'.

Do we just leave it 'blank' if its unknown? (i think that was the verdict)

If the area was split into 2 or 3 regular polygons... It would be
easier to work with.

(would a diagram help?)

Cheers,
Sam

On 11/4/09, Frederik Ramm <frederik@...> wrote:

> Hi,
>
> Ian Dees wrote:
>> - tags for multipolygon relations have been moved from the relation to
>> the outer ways (fixing a bug with the -t option)
>
> Why that? I think that having tags on the outer way is a legacy thing;
> when I create new multipolygons, I leave the outer way untagged and put
> the tags on the relation only.
>
> This becomes especially important if the outer ring consist of multiple
> ways.
>
> Bye
> Frederik
>
> _______________________________________________
> talk mailing list
> talk@...
> http://lists.openstreetmap.org/listinfo/talk
>

--
Twitter: @Acrosscanada
Blog:  http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
OpenStreetMap IRC: http://irc.openstreetmap.org
@Acrosscanadatrails

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Martin Koppenhoefer]

If the area was split into 2 or 3 regular polygons... It would be

easier to work with.

-1, multipolygons are quite usefull and I think we should keep them and go further in their use. Currently there are still problems with their rendering in mapnik (doesn't cut holes when the inner way is tagged with different tags). I also think that Frederik is right: it should be possible to assemble different outer ways to one outer polygon and define it's meaning with tags just on the relation (or even override the tags from the outer ways when they're not closed).

cheers,
Martin 

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Frederik Ramm]

Hi,

Martin Koppenhoefer wrote:
> I also think that Frederik is right: it should be
> possible to assemble different outer ways to one outer polygon and
> define it's meaning with tags just on the relation

This *is* already possible - and also necessary for (at least!) any
polygon with a geometry of more than 2000 points.

Bye
Frederk

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Emilie Laffray]

2009/11/4 Frederik Ramm <frederik@...>

Hi,

Martin Koppenhoefer wrote:
> I also think that Frederik is right: it should be
> possible to assemble different outer ways to one outer polygon and
> define it's meaning with tags just on the relation

This *is* already possible - and also necessary for (at least!) any
polygon with a geometry of more than 2000 points.

Indeed. The Corine import had quite a few of them. Some are very large with lots of inner polygons too. It was handled properly by osm2pgsql.

Emilie Laffray

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Martin Koppenhoefer]

2009/11/4 Frederik Ramm <frederik@...>

Hi,

Martin Koppenhoefer wrote:

I also think that Frederik is right: it should be possible to assemble different outer ways to one outer polygon and define it's meaning with tags just on the relation

This *is* already possible - and also necessary for (at least!) any polygon with a geometry of more than 2000 points.

OK, everything is possible. Does this work in current renderers, namely t@h? Mapnik has still problems with even most simple m-polygons (one outer  and one inner closed way, tagged differently, no further tags on multipolygon-relation).

cheers,
Martin

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Emilie Laffray]

2009/11/4 Martin Koppenhoefer <dieterdreist@...>

2009/11/4 Frederik Ramm <frederik@...>

Hi,

Martin Koppenhoefer wrote:

I also think that Frederik is right: it should be possible to assemble different outer ways to one outer polygon and define it's meaning with tags just on the relation

This *is* already possible - and also necessary for (at least!) any polygon with a geometry of more than 2000 points.

OK, everything is possible. Does this work in current renderers, namely t@h? Mapnik has still problems with even most simple m-polygons (one outer  and one inner closed way, tagged differently, no further tags on multipolygon-relation).

Well in the case of multiple outers (all joined), multiple inners with tags on relation, Mapnik seems to be handling it fine.

Emilie Laffray

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[acrosscanadatrails]

Some parts of this message have been removed. Learn more about Nabble's security policy.

On Wed, Nov 4, 2009 at 4:46 AM, Emilie Laffray <emilie.laffray@...> wrote:

2009/11/4 Martin Koppenhoefer <dieterdreist@...>

2009/11/4 Frederik Ramm <frederik@...>

Hi,

Martin Koppenhoefer wrote:

I also think that Frederik is right: it should be possible to assemble different outer ways to one outer polygon and define it's meaning with tags just on the relation

This *is* already possible - and also necessary for (at least!) any polygon with a geometry of more than 2000 points.

OK, everything is possible. Does this work in current renderers, namely t@h? Mapnik has still problems with even most simple m-polygons (one outer  and one inner closed way, tagged differently, no further tags on multipolygon-relation).

Well in the case of multiple outers (all joined), multiple inners with tags on relation, Mapnik seems to be handling it fine.

So in otherwords, the 'outer' is not supposed to be tagged eithor? .. and just tags on the relation?

Thanks,
Sam
 

Emilie Laffray

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[yellowbkpk]

On Wed, Nov 4, 2009 at 2:04 AM, Frederik Ramm <frederik@...> wrote:

Hi,

Ian Dees wrote:

- tags for multipolygon relations have been moved from the relation to the outer ways (fixing a bug with the -t option)

Why that? I think that having tags on the outer way is a legacy thing; when I create new multipolygons, I leave the outer way untagged and put the tags on the relation only.

This becomes especially important if the outer ring consist of multiple ways.

Initially I had implemented it so that the tags go on the type=multipolygon relation (and this almost always worked with JOSM and Mapnik), but then I re-read the Relation:multipolygon wiki page [0] and saw that the first section of the page says "tags describing the multipolygon should go on the outer way."

Now that I look at the complex multipolygon part of the page (down at the bottom), it says to put the tags on the relation. I always thought that tags on the relation made the most sense, but was trying to match up with the wiki.

I'm perfectly happy to switch back to putting tags on the relation...

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Anthony-32]

On Wed, Nov 4, 2009 at 7:35 AM, Martin Koppenhoefer
<dieterdreist@...> wrote:
> 2009/11/4 Frederik Ramm <frederik@...>
>> This *is* already possible - and also necessary for (at least!) any
>> polygon with a geometry of more than 2000 points.
> OK, everything is possible. Does this work in current renderers, namely t@h?
> Mapnik has still problems with even most simple m-polygons (one outer  and
> one inner closed way, tagged differently, no further tags on
> multipolygon-relation).

Maybe if we add enough of them it'll get fixed faster :).

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Frederik Ramm]

Ian,

Ian Dees wrote:

>     Why that? I think that having tags on the outer way is a legacy
>     thing; when I create new multipolygons, I leave the outer way
>     untagged and put the tags on the relation only.
>
>     This becomes especially important if the outer ring consist of
>     multiple ways.
>
>
> Initially I had implemented it so that the tags go on the
> type=multipolygon relation (and this almost always worked with JOSM and
> Mapnik), but then I re-read the Relation:multipolygon wiki page [0] and
> saw that the first section of the page says "tags describing the
> multipolygon should go on the outer way."

What's most embarrassing is that I wrote that recommendation 18 months
ago and it has never been changed. Until a few minutes ago ;-)

It's really not a big deal at the moment but my motivation to recommend
tagging the relation is mainly because of

(1) consistency - if you have more than one outer way you must tag the
relation, so why not do it if you only have one, too.

(2) future proof - I'm thinking of the multipolygon relation as the
nucleus of a future area data type, thus it makes sense for me to tag
the multipolygon (the area) and not its building blocks.

Entirely my opinion of course.

Bye
Frederik

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Anthony-32]

On Wed, Nov 4, 2009 at 8:08 AM, Sam Vekemans
<acrosscanadatrails@...> wrote:
> So in otherwords, the 'outer' is not supposed to be tagged eithor? .. and
> just tags on the relation?

I think the idea is that a tag on the outer represents the way or
polygon, not the multipolygon.

Say you have an island, which consists of a beach and a lake.  You'd
put an outer way around the island, an inner way around the lake, tag
the relation with natural=beach, tag the inner with natural=water, and
tag the outer with "name=whatever island" (since the whole thing is
the island, not just the beach part).

Right?

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[yellowbkpk]

This actually sounds relatively easy to do... I will look into it before releasing the new version that puts tags back on relations.

Anyone else have relatively simple feature requests for shp-to-osm. I will have a little bit of time today.

On Wed, Nov 4, 2009 at 9:00 AM, Serge Wroclawski <emacsen@...> wrote:

Here's a tricky request (or request for a suggestion on how to solve):

In DC we've been running these import sprints. shp-to-osm is now
centerpiece in presenting users with baked OSM files which they just
have to check manually against the data and import.

Taking a simple example, I might have a file with a few hundred points.

Ideally what I'd like to do is give a user a managable chunk of work.

So, you may think "Just set the max nodes per file to something small, say 10".

The caviot is twofold:

1) That usually works but I can't guarantee that the nodes will be
close to one another. It'd be better to have bounding boxes, rather
than counts.

2) Nodes counts don't work when we're working with ways or relations.


Thoughts? Maybe some magic I can feed to QGIS to pre-process the data?

- Serge

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[yellowbkpk]

I cut a new version (0.7.1) that fixed a few bugs I introduced when adding features and reverted to putting tags on the relation.

Pick it up in the same spot.

On Tue, Nov 3, 2009 at 10:38 PM, Ian Dees <ian.dees@...> wrote:

I just uploaded shp-to-osm 0.7, a Java tool to convert shapefiles to OSM format.

This version adds two important features:
- "glomming": the ability to connect ways based on a key/value pair
- tags for multipolygon relations have been moved from the relation to the outer ways (fixing a bug with the -t option)

Download it here:
http://redmine.yellowbkpk.com/projects/list_files/geo

File bugs/feature requests here:
http://redmine.yellowbkpk.com/projects/geo/issues/new

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Pieren Pieren]

On Wed, Nov 4, 2009 at 10:02 PM, Ian Dees <ian.dees@...> wrote:
> I cut a new version (0.7.1) that fixed a few bugs I introduced when adding
> features and reverted to putting tags on the relation.
>
> Pick it up in the same spot.
>

Apart from this tool, I don't like the idea of always putting the tags
in the relation. If you only have tags on the outer ring, why not. But
we also have very often tags on the inner ring. And I don't see why we
should have sometimes the tags in the ways and sometimes in the
relations just because they use a special relation type. I could also
say that the tags in the inner ring have the same right to be in the
relation as the outer ring.
Pieren

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Norbert Hoffmann]

Pieren wrote:

>Apart from this tool, I don't like the idea of always putting the tags
>in the relation. If you only have tags on the outer ring, why not. But
>we also have very often tags on the inner ring. And I don't see why we
>should have sometimes the tags in the ways and sometimes in the
>relations just because they use a special relation type. I could also
>say that the tags in the inner ring have the same right to be in the
>relation as the outer ring.

Try to see it like this: A tag on a ring describes a property that belongs
to the whole inside of the ring. So a tag on an "inner" ring has nothing to
do with the relation (that's the meaning of "inner" - an area that does
*not* belong to the area described by the relation).

For "outer" rings it is similar: If you tag a property to the relation you
explicitely say: this property does not belong to the holes (marked with
"role=inner). If you tag the outer ring you don't make clear what you mean.

Norbert


_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Martin Koppenhoefer]

2009/11/5 Norbert Hoffmann <nhoffmann@...>

Pieren wrote:

>Apart from this tool, I don't like the idea of always putting the tags
>in the relation. If you only have tags on the outer ring, why not. But
>we also have very often tags on the inner ring. And I don't see why we
>should have sometimes the tags in the ways and sometimes in the
>relations just because they use a special relation type. I could also
>say that the tags in the inner ring have the same right to be in the
>relation as the outer ring.

Try to see it like this: A tag on a ring describes a property that belongs
to the whole inside of the ring. So a tag on an "inner" ring has nothing to
do with the relation (that's the meaning of "inner" - an area that does
*not* belong to the area described by the relation).

For "outer" rings it is similar: If you tag a property to the relation you
explicitely say: this property does not belong to the holes (marked with
"role=inner). If you tag the outer ring you don't make clear what you mean.

I have an example:
St. Peter's Square in the vatican city. (Please ignore the inconsistent state, I will continue mapping the southern parts of the colonnades more precisely asap):
http://www.openstreetmap.org/?lat=41.902187&lon=12.457628&zoom=18&layers=B000FTF

it is a square with 2 fountains and 1 obelisk on it. All of them are mapped as polygons.
The name "St. Peter's square" should go on the outer polygon as it is comprising fountains and obelisk (it is mapped like this). The latter should have their own name and tags (it is mapped like this). The tags for the square (pedestrian area) are currently attached to the outer way but I should put them to the multipolygon-relation instead, as the obelisk and the fountains don't belong to them.

Still there is a rendering probem, because if the fountains _were_ part of the pedestrian area, it would already be mapped correctly, but not displayed correctly in mapnik.

cheers,
Martin

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Frederik Ramm]

Hi,

Pieren wrote:
> Apart from this tool, I don't like the idea of always putting the tags
> in the relation. If you only have tags on the outer ring, why not. But
> we also have very often tags on the inner ring. And I don't see why we
> should have sometimes the tags in the ways and sometimes in the
> relations just because they use a special relation type. I could also
> say that the tags in the inner ring have the same right to be in the
> relation as the outer ring.

Having tags on the inner ring is a compromise between correct modeling
and saving work for the mapper.

In computational geometry, a multipolygon can have holes, but these
holes do never have an identity of their own - they are just the absence
of whatever the multipolygon represents. Thus a hole in a forest is
simply something where there is no forest - it doesn't say what is there.

If you wanted to model things correctly then you would have one area
object for the multipolygon (e.g. the forest), and another area object
for the area inside the hole (say a lake).

multipolygon #1
   member role="outer" way=#10
   member role="inner" way=#11
   tag natural=wood

multipolygon #2
   member role="outer" way=#11
   tag natural=water

It's just that we do not want to create so much work for the mappers,
that's why we allow a shortcut: "If you have an area that has no holes
and just one outer ring, then you can tag the outer ring accordingly and
it will be recognized as a polygon".

So yes, I do agree with you that this is not "clean". But I do not agree
with your conclusion ("just because we allow some things to not be
clean, let's just drop clean modelling altogehter").

Bye
Frederik

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk