[OSM-talk-ie] Corine Import - update

Dermot McNally dermotm at gmail.com
Tue Feb 8 22:49:35 GMT 2011


HI,

On 8 February 2011 22:19, moltonel 3x Combo <moltonel at gmail.com> wrote:

> It obviously isn't perfect, but it's a great step forward and I'm
> happy to manually fix things once the import is done. I looked at
> Jenkinstown woods, which I know well, and that particular example fits
> the general feel I have of the corine data.

Excellent. That's more or less what most people are saying.

> About that, will there be a tool to look for overlapping corine/old
> data, so that they can be manually checked ? Or should we just look
> for corine:reviewed=no tags ?

Earlier in this process I stated that the JOSM plugin should detect
the overlaps - but in my tests so far, that doesn't seem to be the
case, or else I was just unlucky. Perhaps it will detect them for only
some kinds of land cover. Tools like Keepright may be better, but we
won't see exactly how they behave until we actually do the import,
since they only ever target production data.

Basically we are free to do our own work (and it shouldn't be that
hard) to improve the existing validators or write our own. But in
addition to this, and to your idea of just reviewing every Corine
polygon (because that will take a while), we can do a lot by a visual
scan of a pre-import data set for Ireland (or maybe an extract of,
say, all forests from the last pre-Corine Ireland extract). The idea
would be to pick off pre-existing land polygons one by one in the
editor and do any cleanup required. You wouldn't want to do every
landuse polygon in Ireland like this, but for the larger polygons that
exist already it will give us some quick progress. Clearly if we all
look to de-dupe those areas we know we've mapped ourselves that will
also help. landuse=residential will be particularly fiddly for those
of us who apply this to individual estates, since we'll likely want to
punch holes in the Corine all-town polygon everywhere we have mapped
estates like this.

> * are relations like
> http://apidev2.openstreetmap.ie/browse/relation/1405521 one part of
> the "big meadow polygon covering all of Ireland" you mentioned in a
> previous email ?

That is an example of a relation, though not all relations will be
quite like that. This particular kind of relation (what OSM calls a
multipolygon) is a selection of areas, some considered the outer
boundaries and some considered the inner boundaries of a polygon. If
there are inner areas, the polygon is considered to have "holes", as
this one does.

But at its most basic level, a relation is just a data structure in
OSM that can contain arbitrary numbers of nodes, ways and other
relations. So you also get them used for turn restrictions (These
contain a "from" way, a "to" way and a "via" node and then the
relation is tagged to say what kind of restriction applies). The idea
that different relation members can have different meanings in the
complex object (outer, inner, from, to, via etc.) is why each member
of a relation can be tagged with a "role".

> * will any and all "landuse=foobar" zones from now on be part of a
> relation instead of a simple closed way ? Is that so that no gap exist
> between different landuse= zones ?

All imported Corine polygons will be of this sort, but they will
co-exist happily with any done with simple ways. There will be no
obstacle to drawing future landuse areas as simple closed ways either,
though if they share boundaries with other areas, it might be better
not to (I'll come back to this). Indeed, it might even be valid for
some Corine areas to replace them with simple way-based areas if that
seems most appropriate.

You've asked whether the motivation is avoidance of gaps. It's more
the other way around. There are lots of opinions in OSM about whether
it is "correct" or "pragmatic" (considering ease of maintenance) to
"glue" areas together in this way - but _if_ you choose to do so, you
have a choice of two mains methods:

1. Simple closed polygons sharing nodes. This will cause the ways
bounding neighbouring polygons to overlap making it (somewhat) harder
to reliably select the one you want and giving rise to some mapper
confusion.

2. Single ways between touching areas. Each area is formed of a
relation containing each of the many separate boundary ways that make
up its perimeter, so no overlapping ways. The drawback is that
relations are themselves more complex and many mappers are no better
able to deal with them than with overlapping ways. But this is
considered the more "refined" solution, and it has one other important
gain for this purpose, which I'm about to come to...

It so happens that the Corine area data that we have is glued, so that
was unavoidable. Option 1 isn't very nice for Corine, for two reasons.
Firstly, bad things happen when node count on an area perimeter
exceeds about 2000 nodes. And although we were able to take
preventative measures when we found the pasture polygon of death, we
couldn't be sure that there would be no polygons with too many nodes.
But the fact is, because our import data inherently contained holes
that were too hard to pre-process away, we had to use multipolygons
anyway, so we may as well split the perimeter ways and use the cleaner
option 2.

> * what is the technical reason of, say
> http://apidev2.openstreetmap.ie/browse/way/96795458 and
> http://apidev2.openstreetmap.ie/browse/way/96813263 being two
> different ways instead of one ?

At first glance, that looks like an overlapping pair of ways that
ought to be a single one. There are a handful of such cases that I
found when validating the import in JOSM, but JOSM is too slow with a
whole country loaded for me to fix them before import. I think the
number was in the 20s.

> * When we'll manually merge corine and existing data in some area, in
> the case where the old data is best, should we modify corine data to
> fit the existing polygon and then remove that one, or delete the
> corine poly and then incorporate the old poly into the corine
> multipoly ?

Whatever seems best, I feel. Here's a selection of likely actions,
depending on the circumstances:

* Existing data is perfect, Make a hole in Corine to accommodate it,
Corine polygon shrinks
* Existing data is perfect, but can gain from some of the tags on the
Corine data (tree type for forests, say) - as above, but copy the tags
first.
* Existing data is well-shaped (a lake, say), Corine is more
generalised, but more accurately located. Move old data to Corine
location, delete Corine relation (though probably not all ways, as
they may be used by other polygons. (yikes).

> I'm sure most of those questions are due to me being a newbee
> regarding relations rather than any fault of the proposed import,
> sorry.

On the contrary, your instincts are proving very sharp on this, and
this truly is fairly complex OSM stuff of a sort that many mappers
avoid. (Avoidance remains an option, of course, for those wishing to
take it. Even if you have landuse you need cleaned up, others will be
on hand to help)

> I suppose any edit we make to http://apidev2.openstreetmap.ie/ will be
> thrown away at import time, so that we can fearlessly play with and
> break the data ?

Yes, completely, play away. Just note that your changes won't render,
since the tiles you see on that box come from elsewhere.

> Thanks again for the consciencious work you're putting into this.

Well, it has to be done right, or those of us doing the import will
get our asses kicked ;)

Dermot

-- 
--------------------------------------
Igaühel on siin oma laul
ja ma oma ei leiagi üles



More information about the Talk-ie mailing list