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." Verdy_p: " 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 frequent updates. 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 frequently changing. 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)." ----- Ciao, Martin
_______________________________________________ Talk-it mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-it
