[Talk-ca] Discussion: zones boisées

[Frank Steggink]

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