[Talk-it] relazioni amministrative in Italia -
dieterdreist a gmail.com
Lun 14 Dic 2015 09:02:56 UTC
Scusate l'enorme ritardo, volevo informare che ho ottenuto da tempo
risposta sia da SldrHartman che da Verdy_p, ecco:
SldrHartman: "ciao ok, procedete come meglio preferite."
The hint on the wiki was added much later, and in most countries the tag is
disarable, notably because those relations are in contruction and require
The documentaiton is there since long and in facxt does not impact anything
in the way items are found or loaded.
Even if people want to load those relations in an editor, the suareas MUST
also be loaded in order to edit them also properly (because their boundary
ways are shared between touching relations of the same type or with borders
of subareas delimited inside of them.
There's absolutely no problem loading relations: editors will load just was
is needed and don't need to load all members of subarea relations, but will
load automatically the ways or nodes that are shared. Not loading these
suelements will create very frequent edit errors, such that one relation is
broken unexpectedly by ediing another using the same ways.
The concept of child/parent relations is standard in OSM since long.
Romoving the subareas just means more frequent errors, even in regions
where all administrative regions are already defined, becuase they need to
be refined further, or because the administrative subdivisions are also
If your editor loads too many items, it is a problem of the editor, but it
does not break any data.
But this causes absolutely no problem in the most frequently used tools :
iD, JOSM, Nominatim, Mapnik and MapQuest renderers...
In fact only a few users were intrigeted about them but nothing is wrong.
Those elements just add ONE and ONLY ONE member item per administrative
subdvision in its parent subdivision relation: this is very small in fact
compared to the definition of ways and nodes in those relations of ways, or
even compared to their tags. But very useful for editors, as well as
reusers (geometric searches are extremely costly and have low performance,
they also do not find all the needed items (and notably not when any
relation has been partly broken because users did not load all the needed
relations when they edited them and broke others).
Repairing broken relations is also much easier with these elements. And it
is much easier to track all the needed changes (notably when there's a
large administrative reform, for which those elements are really needed to
work with incomplete data, sometimes during many months)."
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
Maggiori informazioni sulla lista