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
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
