-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/12/2011 09:33 AM, Giacomo Boschi wrote:
> Il 11/03/2011 13:18, M∡rtin Koppenhoefer ha scritto:
>
>> Personalmente trovo che mappare i singoli campi (ovviamente molto più
>> lavoro, ma pian piano si fa) è un approccio che funziona molto meglio
>> e trasporta molto più informazioni (della topografia).
>
> Perfettamente d'accordo
+1
Anche io sono d'accordo sul poter inserire le informazioni sui confini
tra varie aree, siano essi fisici o meno ( es. confini di proprietà dove
non ci sono elementi fisici che li evidenziano)
>
>> Quindi sono convinto che arrivato ad ulteriori livelli di dettaglio
>> sarà il modo preferito, e tutti i multipoligoni di adesso che crescono
>> nel frattempo ci crearanno tantissimo lavoro per scoglierli.
>
> Qui invece vorrei perorare la causa dei multipoligoni. Il problema che
> hai descritto mi sembra più dovuto alla volontà di fare un mapping
> generico piuttosto che all'uso dei multipoligoni. Bene spingere gli
> utenti a mappare i singoli campi, ma perché continuare ad usare solo
> nodi e linee per mappare delle aree? Non è meglio usare un dato di tipo
> apposito quali sono appunto le relazioni multipolygon?
>
> Ad esempio, consideriamo due campi separati da un muretto. Senza
> multipoligoni devo ripassare tre volte sullo stesso segmento: una volta
> per taggare il muretto, la seconda per taggare il bordo di un campo e la
> terza per taggare il bordo dell'altro campo. Con i multipoligoni invece
> basta disegnare il muretto una sola volta (taggandolo come tale), poi
> con le relazioni indico che quella siepe costituisce il bordo fra due
> campi adiacenti.
>
> Non solo è molto più pulito, ma è anche molto più intuitivo, se il
> software permette di gestire le aree con la stessa facilità con cui si
> gestiscono i nodi e le way (cosa a cui pian piano ci stiamo avvicinando).
>
Qui sono d'accordo con Giacomo;
poniamo il semplice caso di un campo agricolo fisicamente omogeneo ma
suddiviso in due proprietà (no muretti, sentieri o alberi che lo splittano).
Con i multipolygon è possibile mappare il campo indicando il confine di
proprietà con una way ed inserendo due relazioni che condividono quella
way. Il confine non viene renderizzato ( a meno di renderer adhoc ); ma
l'informazione c'è.
Così facendo si evita l'inserimento di nodi e ways sovrapposti che
secondo me sono sicuramente uno spreco di risorse ( ragionando
globalemente il db di osm diventerebbe n volte più grande sovrapponendo
i confini delle varie features ).
Inoltre credo che in questi casi non sfruttare i multipolygon possa
condurre ad uno dei seguenti errori:
- topologici: la forzatura di tracciare i confini di due campi
adiacenti lasciando un bordo vuoto quando in realtà non c'è nulla che
fisicamente separa i due campi.
- semantici: due ways landuse=farmland diverse che hanno alcuni nodi
consecutivi sovrapposti credo siano una inconsistenza semantica. (al
contrario di una way che rappresenta più cose diverse)
Leonardo
- --
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk186X4ACgkQJtMu4PhtcJ/AoQCgko3x2A+Sg+uRodJPnjqkiEvx
IZMAoKQJiGXiBjDETgnT9Uun+j5qgVr/
=kNVA
-----END PGP SIGNATURE-----
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
