HI, On 8 February 2011 22:19, moltonel 3x Combo <[email protected]> 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 _______________________________________________ Talk-ie mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ie
