Salut Dega,
You're right but that's a moot point.
From my point of view, OSM is not a tool for GIS professionals. It's a
community project ("activité citoyenne"). From a scientific and rigorous
perspective, a forest must have a hole for any 2D entity (lake, river, road,
street and building). But, if you go that way, editing the map will become so
complex (or arduous as you say) that no normal contributor will be interested
any more.
OSM is used pretty much by GIS professionals. For example in the
Netherlands, the OSM roads are used in different kinds of publicly
available maps, like on opentopo.nl, and the default map on PDOK
(government open geodata portal), for example here: http://kaart.pdok.nl/
GIS professionals and non-professional alike can both have needs to use
only a part of OSM. Not just for analysis, which was just an example,
but what if you want to make a map with only forests, and not all kinds
of land use?
Also, just drawing other features on top of forests, without cutting
them out, can be seen as an example of "tagging for the renderer". In
order to get nice results, one is always obliged to draw smaller
features on top of larger features.
Look at this "monstruous" way:
http://openstreetmap.org/way/175486790
It's a CanVec import with 1420 nodes, part of relation 2344036.
The way was imported after many of the streets have been created. So the
forest is "on top" of streets and roads and there's no hole for them.
Do you really think a human being will get satisfaction and pride if he/she
have to dig holes around every street?
Of course not. In theory this might even be done automatically, but I
think that would be too dangerous. We could develop a JSON plugin, test
it to see it feasible, and then only distribute it to a couple of people
who can be entrusted with it. --> see also the suggestion below.
For now I'm thinking about a solution for this problem. I also see the
large multipolygons as a problem. They're unwieldy. At the Dutch
national mapping agency special software has been written (based on
ArcGIS) which can deal with this stuff. They're based on a strict set of
rules how to deal with situations where various features meet. They're
called "surveying rules", named after the period when the topographers
still went outside to do surveying.
And look at the above example. The golf course is on top of the forest
(without a hole) albeit it has a significant area.
Is it in the same area? I can't find it.
It the goal is to use the OSM database as a rigorous GIS ressource, then the
tools designed for humans (Id, Potlatch, JOSM) will have to be modified to
automatically create a hole around any 2D object. If they are not modified, you
may say goodbye to normal contributors.
There is a certain kind of learning curve. In my opinion it is necessary
to have a certain kind of quality. Not all contributors need to be able
to deal with it. There are a lot of other things they can add if they
don't know how to deal with the tools. The tools can also be made more
simpler, for example offering to cut landuse which is intersecting with
the road. Or add a tool where you can cut landuse when it is
intersecting other features. Workflow: 1) select landuse + second
feature (road), 2) press button, 3) voila. It would be nice to add some
buffer distance, but that might also become too hard to manage, because
of the countless situations.
You may also broadcast this message to Europe because the first european forest
I looked at do not have holes for lake, rivers and roads.
http://www.openstreetmap.org/#map=15/52.1965/-3.8386
There are many more examples like this. Because there are some users who
have trouble handling multipolygons, that doesn't mean they should not
be used at all! I think there is still a difference between a
multipolygon which are still considered fairly simple (say < 5 holes,
and an outer way with 100 or less nods), or which are too complex to
deal with (many Canvec multipolygons).
Regards,
Frank
_______________________________________________
Talk-ca mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-ca
