[OSM-dev] Call for A Proper Area Datatype for OSM

[Peter Wendorff]

Am 10.02.2013 21:57, schrieb sly (sylvain letuffe):
> Le dimanche 10 février 2013 21:31:28, Jochen Topf a écrit :
>
>> Actually the transition is the easy part.
> I am uneasy with your use of the work easy ! What will be the harder part !
>
> "Just add support in every editors, most data consumer tools and export/api
> side, update the api so you don't download all coastlines at once, run a
> script for converting while keeping history intact, still allowing reverts" is
> what you would call easy ? I admire your enthusiasm ;-)
Fortunately it should be easy
1) to keep some kind of backward compatibility:
1.a. download from the api: The API could e.g. support a compatibility 
switch that forces returning the new areas as the old ways with an 
additional "area=yes"-Tag. area=yes is in fact already used for stating 
that this feature should be interpreted as an area. Without that switch 
the areas could be produced as the new area-objects/tags.
1.b. upload to the api: For compatibility here the area=yes could be 
some standard tag for "this is an area", which could trigger the api to 
check if it's possible to create an area out of the way or not, and do 
so if it's possible.

2) to enhance editors:
2.a. JOSM: already supports area styling at least; it should not be that 
difficult to introduce the area object as a fourth primitive.
2.b. P2: as far as I know P2 has area support in the sense that areas 
are dealt with differently in code.
2.c. iD definitively handles areas differently already.
2.d: other editors shouldn't be much harder, I would guess - and if it 
takes time, see (1) above.

...provided that (as you mentioned already)...
3) ...the problem of really big areas is solved: Downloading the whole 
coastline of Australia is far too much for many editors, the API and 
often for the main memory is an sometimes impossible challenge. But that 
probably has to be solved nevertheless, and if, I believe, we could find 
a compatible solution again. One idea that comes to my mind might be to 
allow downloading "area-extracts" (as well as way-extracts). This could 
be done similar to what we have for relations already: Relations often 
are not completely downloaded in josm, and the relation editor deals 
well with that issue. For ways something similar could be done:
Load way X in bbox B would lead to all nodes in B (and the next one 
outside) as "real nodes" as well as "pseudo nodes" to provide an 
estimated area around. Editors could use the result for drawing the 
polygon as usual (and for the first time they would succeed in filling 
areas correctly even if not loaded completely, where they fail for 
multi-outer-mp-relations yet), and the API could accept something like 
incomplete-edit-calls for areas, like "edit way X: old node index range 
[3..123] out of version 7 changes to the use of nodes [.......] (might 
be less nodes, more nodes or the same node count, but the first two 
nodes keep unchanged, and the nodes behind index 123 doesn't change 
either)". Even more than one node range could be manipulated this way.
I know: there are more issues, even with this short sketch of an idea 
(like e.g. "locking" (you usually can only edit an osm object nobody 
edited since you downloaded it)), but I'm sure it's possible to solve 
these as well.

regards
Peter