>> mappare nome volgare come genus:it?
> species:it?
Il dataset ha i campi nome scientifico e nome volgare. Ricapitolando dalla
wiki [1]:
species=* è il nome scientifico
genus=* è la prima parte del nome scientifico (ridondante se hai species)
quindi, per esempio da
species=Quercus robur L.
pos
On Mon, Oct 22, 2018 at 10:37 AM Cascafico Giovanni wrote:
> Ma il nome volgare "Farnia" dove lo metto?
In species:it
come indicato negli esempi che ci sono nella pagina de te indicata,
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree
oppure come spiegato in https://wiki.openstreetmap.or
Si, ho letto, ma sta wiki mi lascia dei dubbi: se species è il nome
scientifico, species:it dovrebbe esserne la traduzione dal latino, con
tanto di abbreviazione del catalogatore, cosa che farnia non mi pare lo sia.
Io sarei per genus:it=Farnia
Il lun 22 ott 2018, 19:26 Any File ha scritto:
> On
Non vorrei sbagliarmi, ma mi sembra che il metodo più flessibile e
scientificamente corretto per /taggare /entità biologiche consista
nell'utilizzare la key "taxon" [1], il cui scopo è proprio quello di evitare il
proliferare di chiavi per differenti per i vari elementi tassonomici dato che
"t
Ciao,
On Tue, Oct 23, 2018 at 10:40 PM Cascafico Giovanni
wrote:
> Si, ho letto, ma sta wiki mi lascia dei dubbi: se species è il nome
> scientifico, species:it dovrebbe esserne la traduzione dal latino, con
> tanto di abbreviazione del catalogatore, cosa che farnia non mi pare lo sia.
> Io sare
Il giorno mer 24 ott 2018 alle ore 08:32 Andrea Musuruane <
musur...@gmail.com> ha scritto:
> Ciao,
>
> On Tue, Oct 23, 2018 at 10:40 PM Cascafico Giovanni
> wrote:
>
>> Si, ho letto, ma sta wiki mi lascia dei dubbi: se species è il nome
>> scientifico, species:it dovrebbe esserne la traduzione d
Ciao,
temo di essermi spiegato male.
On Wed, Oct 24, 2018 at 8:51 AM Cascafico Giovanni
wrote:
> Ricapitolando, cercando di fissare un "tragging plan" [1]
>
> species è il nome scinetifico, per cui non ci sono dubbi
>
species è il nome della specie. Nel tag si mette il nome scientifico
(Que
Il giorno mer 24 ott 2018 alle ore 09:16 Andrea Musuruane <
musur...@gmail.com> ha scritto:
>
> Ricapitolando:
> *species=Quercus robur *
> *species:it=Farina*
> * genus=Quercus*
>
> * genus:it=Quercia *
>
> Solo il primo è necessario. Gli altri sono tutti opzionali.
>
Grazie, aggiorno il paragra
sent from a phone
> On 24. Oct 2018, at 09:29, Cascafico Giovanni wrote:
>
> il ridondante species:it lo inserirei comunque perchè (per gli ignoranti come
> me) è un'informazione utile
l’idea era di poter inserire specie senza conoscere il nome latino, ma quando
lo sai direi che è inutile
Che ne dite di questo [1] tagging?
natural=tree
ref=28/l483/UD/06
circumference=3 
ele=170 
height=20 
leaf_cycle=deciduous 
leaf_type=broadleaved 
taxon=Cupressus cashmeriana 
taxon:it=Cipresso del Cashmere 
[1] http://audit.osmz.ru/run/AM-RAFVG/33
>
>
_
Perfettamente d'accordo sul "taxon=Cupressus cashmeriana"
Anche "circumference" e "height" mi sembrano corrette, ma... cosa si fa quando
(/com'è naturale/) l'albero cresce? Serve un riferimento temporale che
stabilisca quando le misure sono state fatte?
"ele" può anche andare bene, ma in realtà
A mio avvisto "mappare" le misure di un qualcosa che le cambia col tempo
non e' esattamente corretto: cioe', in teoria si mappa cio' che non e'
effimero (o almeno che potrebbe non esserlo). Le misure di un albero,
altezza e circonferenza, cambieranno PER FORZA nel corso del tempo...
Il giorno ven
Concordo, ma d'altro canto sono info che potrebbero avere una certa rilevanza,
sopratutto quando si tratta di "misure eccezionali" che potrebbe essere
interessante segnalare. Forse meglio in note=* o note:it=* ?
On 2018-10-26 14:40, Gabriele Sani wrote:
> A mio avvisto "mappare" le misure di u
... o anche lasciare height e circumference e mettere una note del tipo
"note=Height and circumference as of 2018-10-26"
On 2018-10-26 14:46, Sergio Manzi wrote:
>
> Concordo, ma d'altro canto sono info che potrebbero avere una certa
> rilevanza, sopratutto quando si tratta di "misure ecceziona
Il dataset degli alberi monumentali elenca alberi "cresciutelli" :-)
I sopralluoghi sono stati fatti tra il 2013 ed il 2018: credo sia
sufficiente un source:date sul changeset per dedurre improbabili modifiche
dimensionali.
Piuttosto verranno fatti gli aggiornamente sui nuovi inclusi nel catalogo e
Sui tag per le foglie: Osm non è un catalogo per naturalisti, ne' un entry
point di wikidata. Non pensate che un paio di semplici tag possa aiutare
meglio per esempio un turista?
Eppoi perché allora creare i tag leaf_type e leaf_cycle?
Il ven 26 ott 2018, 14:27 Sergio Manzi ha scritto:
> Perfett
L'idea che me ne sono fatto è che servano soprattutto a descrivere boschi
(natural=wood) [1] in cui c'è una popolazione non omogenea di diverse specie di
piante, ma globalmente/prevalentemente dalle stesse caratteristiche.
Concordo che OSM non sia un catalogo per naturalisti e che "/presentare/"
sent from a phone
> On 26. Oct 2018, at 14:40, Gabriele Sani wrote:
>
> A mio avvisto "mappare" le misure di un qualcosa che le cambia col tempo non
> e' esattamente corretto: cioe', in teoria si mappa cio' che non e' effimero
> (o almeno che potrebbe non esserlo). Le misure di un albero, al
sent from a phone
> On 26. Oct 2018, at 14:14, Cascafico Giovanni wrote:
>
> Che ne dite di questo [1] tagging?
>
> natural=tree
ok
> ref=28/l483/UD/06
questo lo vedo scritto sull’albero? Io darei un’indicazione di chi è il ref,
tipo
ref:xyz=*
> circumference=3 
ok
> ele=170 
sent from a phone
> On 26. Oct 2018, at 16:00, Cascafico Giovanni wrote:
>
> Osm non è un catalogo per naturalisti, ne' un entry point di wikidata. Non
> pensate che un paio di semplici tag possa aiutare meglio per esempio un
> turista?
il turista potrebbe usare un’app che mette insieme os
sent from a phone
> On 26. Oct 2018, at 16:55, Martin Koppenhoefer wrote:
>
> Se tu vedi nei dati un albero alto 20metri e di una certa età e specie, puoi
> anche immaginare 5 anni dopo che forse potrebbe essere cresciuto un po’, ciò
> non toglie l’utilità dell’informazione.
scusate, ripro
Sì, ma coste, fiumi e montagne *normalmente *cambiano in una scala di tempo
molto più lunga: non per nulla si usa dire "tempi geologici" per indicare un
lungo lasso di tempo...
Sono d'accordo nell'indicare, le dimensioni dell'albero (/soprattutto quando
"interessanti"/), ma la tua stessa frase
sent from a phone
> On 26. Oct 2018, at 17:09, Sergio Manzi wrote:
>
> ma la tua stessa frase spiega perché sarebbe opportuno fornire anche un
> riferimento temporale alla misura: tu dici "... puoi anche immaginare 5 anni
> dopo che forse potrebbe essere cresciuto un po’ ..." e io ti chiedo
D'accordo su tutta la linea, ma... ci vedi qualcosa di sbagliato nel mettere
una "note"?
On 2018-10-26 23:31, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 26. Oct 2018, at 17:09, Sergio Manzi mailto:s...@smz.it>>
> wrote:
>
>> ma la tua stessa frase spiega perché sarebbe opportuno
il ref è del ministero ed usano lo stesso schema in tutti i documenti excel
delle regioni, per cui direi
ref:mipaaft.
Per ele, il datum non è idefinito. Suppongo sia stato quello che leggevano
i rilevatori sul gps. Vedrò di fare qualche campionamento.
Sull'uso di species o taxon, avevo inizialmen
Ciao Giovanni,
On 2018-10-27 10:58, Cascafico Giovanni wrote:
> il ref è del ministero ed usano lo stesso schema in tutti i documenti excel
> delle regioni, per cui direi
> ref:mipaaft.
Può essere utile aggiungere un riferimento temporale (es. mipaaft2018) per
distinguere potenziali successiv
>
> Il mio dubbio riguardo al dato "ele" è se (*non so...*) venga sempre
> visualizzato sulla mappa quando presente.
>
No, mi pare non sia visualizzato nemmeno se è l'unico tag.
Inoltre, forse, è preferibile utilizzare questo dato solo quando sia
> certificato (*parliamo comunque di certezza uman
Ci sono de aspetti che non son stati menzionati, mi sembra:
(1) Che cosa facciamo per capire se un albero da importare è un doppione di
un albero già presente in OSM
(2) Ci sono in OSM (nel Veneto) in qualcosa come 140 mila alberi (
http://overpass-turbo.eu/s/D9M)
Il problema, già sollevato e disc
Si esegue la conflation su natural=tree e denotation!=null
L'eventuale doppione (definito dai tag sopra ed in un certo raggio max) non
viene importato, ma i tag considerati "master" vanno a rimpiazzare o ad
aggiungersi al nodo preesistente.
Alla fine ci saranno 140,000 più una-due centinaia, ma q
sent from a phone
> On 27. Oct 2018, at 17:41, Volker Schmidt wrote:
>
> importando in alcune zone ben limitate questi 140 mila alberi, che, in più in
> tanti casi non corrispondono a nessun albero sul terreno.
in questo caso va rimosso l’albero da osm. Se ci sono resti, potrebbe essere
co
> Si esegue la conflation su natural=tree e denotation!=null
>
Questo mi era chiaro
L'eventuale doppione (definito dai tag sopra ed in un certo raggio max) non
> viene importato, ma i tag considerati "master" vanno a rimpiazzare o ad
> aggiungersi al nodo preesistente.
>
Non va bene, perché in q
Ciao Giovanni,
scusami, hai perfettamente ragione: parlando di "/certificazione/" dei dati ho
usato un termine assolutamente errato che capisco possa dare adito ad infinite
discussioni. Non era mia intenzione: avrei dovuto parlare di "/affidabilità/" e
in particolare intendevo riferirmi al fatt
P.S.: Nei dati vedo "cose" che temo ci creeranno ulteriori mal di testa: per
esempio in un caso in Trentino vedo nella scheda un "Nome scientifico" definito
come "/Insieme omogeneo di Larix decidua Mill. e Picea abies (L) H. Karst./".
Che si fa??? :-/
On 2018-10-28 13:25, Sergio Manzi wrote:
"Insieme omogeneo" ce ne sono (pochi) anche in fvg. Si possono ignorare o
desidere di aggiugere un tag p.es. fixme=redefine as polygon
Il dom 28 ott 2018, 14:30 Sergio Manzi ha scritto:
> P.S.: Nei dati vedo "cose" che temo ci creeranno ulteriori mal di testa:
> per esempio in un caso in Trentin
Ignorare mi sembra un peccato, il fixme, ci può stare, direi.
Penso anche che non sarebbe male "portarsi dietro" l'ID_SCHEDA, forse in una
"note" ("note=mipaaf ID Scheda: 01/H361/VI/05" oppure, con un po' di
creatività, "note:mipaaf_id_scheda=01/H361/VI/05")
On 2018-10-28 14:34, Cascafico Giov
sent from a phone
> On 28. Oct 2018, at 13:25, Sergio Manzi wrote:
>
> Per questo motivo la mia proposta è di utilizzare per i nomi scientifici del
> dataset mipaaf la chiave "taxon".
per un import escluderei l’ipotesi di appoggiare un tag usato n volte di meno.
Ciao, Martin
dieterdreist wrote
>> Osm non è un catalogo per naturalisti, ne' un entry point di wikidata.
>> Non pensate che un paio di semplici tag possa aiutare meglio per esempio
>> un turista?
>
> il turista potrebbe usare un’app che mette insieme osm con altri fonti.
> Utilità per turisti non è un criteri
sent from a phone
> On 29. Oct 2018, at 08:23, cascafico wrote:
>
> Se tra le linee guida del mappatore c'è l'essere minimalisti con i tag,
> allora mettiamo solo species, poi uno va lìì e si fa le sue deduzioni. In
> fondo si potrebbe giocare sulla sorpresa ;-)
varianti di tag per varie lin
Rispetto la tua posizione, ma... puoi spiegarne i motivi? Quali sono i rischi,
secondo te?
Comunque, /n /è pari a 5.3 (/quindi siamo ampiamente nello stesso ordine di
grandezza/) e inoltre penso che i criteri di scelta debbano essere più
qualitativi che quantitativi.
Prova anche a fare un over
sent from a phone
> On 29. Oct 2018, at 11:17, Sergio Manzi wrote:
>
> Prova anche a fare un overpass-turbo per taxon (puoi limitarti ai nodes) su
> Vienna, Londra o Parigi e vedi cosa salta fuori.
guardando l’andamento è ancora molto più chiaro che taxon quasi non è stato
usato tranne 2 i
Martin,
premesso che su queste cose (/la tassonomia/) gente ben più qualificata di me e
(/suppongo/) te si scorna ormai da centinaia di anni senza arrivare a
conclusioni definitive e che quindi sarà assai difficile arrivare ad un
consenso, come ho già detto il mio criterio di preferenza di /tax
On 2018-10-30 14:36, Sergio Manzi wrote:
> come, per esempio, "family", "variety" o "form"
*Errore:* per consistenza (/nome del livello tassonomico in latino/) dovrebbero
essere "/familia/", "/varietas/" o "/forma/"
smime.p7s
Description: S/MIME Cryptographic Signature
_
Am Di., 30. Okt. 2018 um 14:37 Uhr schrieb Sergio Manzi :
> Martin,
>
> premesso che su queste cose (*la tassonomia*) gente ben più qualificata
> di me e (*suppongo*) te si scorna ormai da centinaia di anni senza
> arrivare a conclusioni definitive e che quindi sarà assai difficile
> arrivare ad u
No, questo è errato: "taxon" _non dice di meno_, perché è il valore associato a
taxon "a dire" di cosa stiamo parlando, non il nome del tag!
On 2018-10-30 15:12, Martin Koppenhoefer wrote:
>
> Ma il termine "taxon" è più flessibile, perché ci permette di
> identificare un "individuo" come a
... è, benché sia vero che abbiamo al 99% abbiamo indicate delle "species",
guarda caso abbiamo anche delle cose tipo "Cedrus atlantica (Endl) Carrière
*var. glauca*" che sarebbe _semanticamente errato indicare come species_.
Inoltre un import come questo può essere l'occasione per *promuovere l
Il 30/10/2018 15:32, Sergio Manzi ha scritto:
Inoltre un import come questo può essere l'occasione per *promuovere
l'uso di taxon*, così come in passato hanno fatto altri (/che, a mio
avviso, "hanno visto la luce/").
Il fatto è che è altamente sconsigliato in un import inserire nuovi tag
o
Ciao Paolo,
grazie per il tuo supporto: incominciavo a sentirmi un po' Don Quixote... :-)
Ti dirò anche che il nome della key, /taxon/, non è quello che io avrei
preferito: penso che sarebbe stato preferibile qualcosa di più facile e
universale comprensione, come, per esempio, "/scientific_nam
qualcuno ha fatto una verifica a campione sulla bontà dei dati? Si vedono
alberi all'esatta posizione nelle foto aeree? Sennò (se la precisione delle
coordinate è qualcosa come 100 metri) la conflation sarebbe impossibile da
gestire. Ho capito bene, parliamo di 200 alberi, solo nel FVG? Che tanto l
dieterdreist wrote
> qualcuno ha fatto una verifica a campione sulla bontà dei dati? Si vedono
> alberi all'esatta posizione nelle foto aeree? Sennò (se la precisione
> delle
> coordinate è qualcosa come 100 metri) la conflation sarebbe impossibile da
> gestire.
Nella pagina wiki [1] trovi il lin
Solo per farvi sapere che ho formalizzato la mia proposta di utilizzare taxon
invece di species, qui:
https://wiki.openstreetmap.org/wiki/Talk:Import/Catalogue/AlberiMonumentali-RAFVG
Ciao a tutti,
Sergio
smime.p7s
Description: S/MIME Cryptographic Signature
___
Ho cercato di raccogliere i pareri di tutti sul tagging nella wiki [1] ed
ho aggiornato la mappa di revisione [2]. Domani vedo si compilarla...
potete partecipare tutti. Attenzione in particolare agli alberi con source
diversa da "Regione FVG". Nel dubbio, uno "skip" od un fixme non fa mai
male :-)
Giovanni,
non capisco le relazioni h_stimata->height e h_misurata->height: non collidono?
O forse nei dati originali l'esistenza di una misura implica l'assenza
dell'altra?
Ciao,
Sergio
On 2018-11-08 14:30, Cascafico Giovanni wrote:
> Ho cercato di raccogliere i pareri di tutti sul tagging n
... nel caso ci siano entrambe, forse si potrebbe fare: h_misurata->height e
h_stimata->height:estimate /(lo so, height:estimate sarebbe una "novità", ma
non mi sembra male e si potrebbe documentare sul wiki../.)
Sergio
On 2018-11-08 14:44, Sergio Manzi wrote:
>
> Giovanni,
>
> non capisco le
... in realtà è già in uso (/ma non molto, vedi/ [1]) una key "est_height", ma
personalmente continuo a pensare che height:estimate sia preferibile...
[1] https://taginfo.openstreetmap.org/keys/est_height
On 2018-11-08 14:53, Sergio Manzi wrote:
>
> ... nel caso ci siano entrambe, forse si potr
Giovanni, scusa se "rompo" ancora, ma...
vedo "cose" che, forse, potrebbero essere migliorate. Per esempio, per l'albero
al nodo https://www.openstreetmap.org/node/2124618451 (/chiaramente
preesistente.../) verremmo ad avere anche queste key:
genus=Tilia
genus:de=Linde
genus:it=tigl
Se non mi è sfuggito qualche post, genus:it è l'unica chiave che abbiamo
trovato dove poter ficcare il nome volgare.
Il type credo sia un errore... sarebbe leaf_type ed eventualmente il suo
compare leaf_cycle.
Sul name:botanical, direi che esula da questo import: se approvato,
potrebbe essere fatt
Le relazione "est_height" | "height:estimate" in taginfo è 1000 a 1!
E poi il simile per "est_width" | "widh:estimate" è 76k a zero.
On Thu, 8 Nov 2018 at 15:04, Sergio Manzi wrote:
> ... in realtà è già in uso (*ma non molto, vedi* [1]) una key
> "est_height", ma personalmente continuo a pensa
sent from a phone
> On 8. Nov 2018, at 15:02, Sergio Manzi wrote:
>
> ... in realtà è già in uso (ma non molto, vedi [1]) una key "est_height", ma
> personalmente continuo a pensare che height:estimate sia preferibile...
>
> [1] https://taginfo.openstreetmap.org/keys/est_height
>
per me è
sent from a phone
> On 8. Nov 2018, at 16:17, Cascafico Giovanni wrote:
>
> Se non mi è sfuggito qualche post, genus:it è l'unica chiave che abbiamo
> trovato dove poter ficcare il nome volgare.
chi ha fatto il dataset, cosa ha usato come chiave specifica, o quale
consideranno il campo p
Martin, Volker,
... mi arrendo di fronte all'evidenza dei fatti! :-)
Ciao,
Sergio
On 2018-11-08 17:32, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 8. Nov 2018, at 15:02, Sergio Manzi mailto:s...@smz.it>>
> wrote:
>
>> ... in realtà è già in uso (/ma non molto, vedi/ [1]) una k
Giovanni, mi sembra che tu ti stia confondendo:
in base al wiki e all'audit che hai citati, il nome volgare va in "species:it"
(nome_volga -> species:it), non "genus:it" (/e concordo!/).
Sergio
On 2018-11-08 16:17, Cascafico Giovanni wrote:
> Se non mi è sfuggito qualche post, genus:it è l'unic
Concordo, mi ha convinro: mi sembra ragionevole rimandare le attività di
"/pulizia di primavera/" ad un fase successiva all'import.
Ciao!
On 2018-11-08 16:17, Cascafico Giovanni wrote:
> ...
> Sul name:botanical, direi che esula da questo import: se approvato, potrebbe
> essere fatto facilment
Rispetto all'inizio della discussione ho poi proseguito la compilazione di
questa [1] pagina. Essa è simile, ma riferita ad un dataset leggermente
diverso ed esplicitamente odbl.
[1]
https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlberiMonumentali-RAFVG-opendata#Record_format_and_tagging_pla
Sì, è a quello che mi riferisco...
On 2018-11-08 22:27, Cascafico Giovanni wrote:
> Rispetto all'inizio della discussione ho poi proseguito la compilazione di
> questa [1] pagina. Essa è simile, ma riferita ad un dataset leggermente
> diverso ed esplicitamente odbl.
>
> [1]
> https://wiki.open
A parte taginfo, non trovo nessuna documantazione su est_height. Credo
siamo in territorio "grigio" di OSM... qualcuno ha documentato est_width,
ma nessuno est_height ne' est_length. Che si fa?
Il giorno gio 8 nov 2018 alle ore 15:04 Sergio Manzi ha
scritto:
> ... in realtà è già in uso (*ma non
Penso che in fin dei conti sia soprattutto importante arricchire il DB di
informazioni utili, di buona qualità, e identificabili.
In questo caso, la scelta tra est_height (/non documentato, ma utilizzato/) o
height:estimated (/sostanzialmento mai utilizzato, ma //a mio avviso
sintatticamente pr
Il giorno gio 8 nov 2018 alle ore 16:17 Cascafico Giovanni <
cascaf...@gmail.com> ha scritto:
> Se non mi è sfuggito qualche post, genus:it è l'unica chiave che abbiamo
> trovato dove poter ficcare il nome volgare.
> Il type credo sia un errore... sarebbe leaf_type ed eventualmente il suo
> compa
+1000!!
On 2018-11-09 11:39, Cascafico Giovanni wrote:
> Il giorno gio 8 nov 2018 alle ore 16:17 Cascafico Giovanni
> mailto:cascaf...@gmail.com>> ha scritto:
>
> Se non mi è sfuggito qualche post, genus:it è l'unica chiave che abbiamo
> trovato dove poter ficcare il nome volgare.
> Il
Il giorno gio 8 nov 2018 alle ore 15:04 Sergio Manzi ha
scritto:
> ... in realtà è già in uso (*ma non molto, vedi* [1]) una key
> "est_height", ma personalmente continuo a pensare che height:estimate sia
> preferibile...
>
Per redere le cosa difficili, ho anche lanciato il sasso [1] anche nello
Ah! Ben fatto!
Adesso mi sono iscritto pure io alla ML tagging e, onestamente, vorrei
contribuire con la mia proposta di utilizzare la sub-key "estimated", ma
essendomi iscritto in un momento successivo all'invio del tuo messaggio, non
sono in grado di rispondere... hai idea di come possa fare?
... forse potresti darmi una mano rispondendo al tuo stesso messaggio (/adesso
la risposta dovrebbe arrivarmi.../) e citando il fatto che qualcuno nella ML
italiana ha suggerito l'uso della subkey ...
On 2018-11-09 11:54, Sergio Manzi wrote:
>
> Ah! Ben fatto!
>
> Adesso mi sono iscritto pure i
Continuo a non essere in grado a partecipare alla discussione nella ML
"tagging, ma in "pipermail" vedo che qualcuno ha fatto un'ottima proposta che
ritengo essere preferibile a quella che avevo inizialmente fatto io:
>/Le 09. 11. 18 à 10:57, Lionel Giard a écrit : />/> You can also use
h
In caso di height stimata , preferirei il semplice tag note [1], usato "to
inform other mappers about [...] hints for further improvement". Avrei
pronto l'audit definitivo [2] :-)
[1] https://wiki.openstreetmap.org/wiki/Key:note
[2] http://audit.osmz.ru/project/AM-RAFVG-OO/
Il giorno sab 10 nov 2
Am Di., 13. Nov. 2018 um 11:02 Uhr schrieb Cascafico Giovanni <
cascaf...@gmail.com>:
> In caso di height stimata , preferirei il semplice tag note [1], usato "to
> inform other mappers about [...] hints for further improvement". Avrei
> pronto l'audit definitivo [2] :-)
>
> [1] https://wiki.opens
Ciao a tutti/e,
On 2018-11-13 11:20, Martin Koppenhoefer wrote:
> per me sarebbe sufficiente mettere "height", perché l'altezza di un albero
> non può essere che stimata. Gli alberi sono flessibili, qualche varianza è
> assolutamente normale.
>
... e per di più sembra che le misure, anche le mis
75 matches
Mail list logo
