Re: [Talk-ca] New mapper

[Pierre Choffet]

Le 14/07/2016 à 13:06, Loïc Haméon a écrit :
> I'm new. I'm looking to improve OSM data in Montreal and
> Lac-Saint-Jean for now. I am however having some difficulties learning
> the ropes and navigating the contact channels.
Bonsoir Loïc, bienvenue dans la communauté OpenStreetMap !

Si tu es aux alentours de Montréal, le groupe local organise demain
dimanche une cartopartie dans l'arrondissement
Mercier-Hochelaga-Maisonneuve. Le principe est de se retrouver ensemble
dans un coin de la ville et de passer l'après-midi à améliorer les
données aux alentours. En l'occurrence, nous allons nous focaliser sur
quelques parcs de moyenne taille qui manquent de détails dans OSM.

Niveau matériel, on a l'habitude de privilégier les téléphones
intelligents ou les tablettes, mais ça marche aussi avec un fond de
carte pré-imprimé que l'on annote sur le terrain.

Bref, si tu veux faire connaissance avec la communauté locale, tu y es
plus que le bienvenu ! L'ambiance est toujours très décontractée, et on
finit toujours par aller boire un verre dans une brasserie du coin une
fois notre dur labeur terminé.

Plus de détails sont disponibles sur le site d'OSM¹, n'hésite pas à me
contacter si tu veux d'autres informations !

1 :
http://www.openstreetmap-montreal.org/cartopartie-%C3%A0-mercier-hochelage-maisonneuve

Pierre





signature.asc
Description: OpenPGP digital signature
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-it] MAppiaM! Mappatura monumenti Appia Antica 9-11 luglio 2016

[Martin Koppenhoefer]

2016-07-16 23:26 GMT+02:00 Aury88 :

> non ho mai detto che descrive il perimetro, ho solo detto dove lo uso, cioè
> su una way chiusa che ricalca il perimetro, ma naturalmente descrive l'area
> compresa  dal perimetro...così come applicando un tag amenity=school sul
> perimetro  non descrivendo in se il perimetro ma l'intera superficie
> scolastica ecc ecc...mi sembrava ovvia come cosa e non ho pensato di
> specificarla :-)
>


l'ho fatto notare perché anche nel caso della scuola si dovrebbe dire: area
della scuola e non "perimetro", perché un way chiuso insieme ad un tag che
denota "area" è soltanto una possibilità per descrivere un poligono,
l'altra è una relazione del tipo multipoligono. Se qualcuno mi dice
"perimetro" penso ad un perimetro, cioè una cosa lineare. Scusa, non volevo
criticarti in particolare, vorrei in generale chiedere di essere preciso
nei termini.
Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-ja] 記念碑でも遺跡でもない記念物について

[ribbon]

最近、産業遺産のように、記念碑でも遺跡でもないような記念物を
よく見かけるようになりました。このようなものはどうやってマッピング
したら良いでしょうか。

ribbon

___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-it] MAppiaM! Mappatura monumenti Appia Antica 9-11 luglio 2016

[Aury88]

dieterdreist wrote
> sent from a phone
> 
>> Il giorno 16 lug 2016, alle ore 20:23, Aury88 

> spacedriver88@

>  ha scritto:
>> 
>> (archaeological_site è usato sul perimetro per indicare il sito e i dati
>> comuni ai vari reperti)
> 
> 
> in realtà non descrive un perimetro ,
>  descrive un'area, un poligono.

non ho mai detto che descrive il perimetro, ho solo detto dove lo uso, cioè 
su una way chiusa che ricalca il perimetro, ma naturalmente descrive l'area
compresa  dal perimetro...così come applicando un tag amenity=school sul
perimetro  non descrivendo in se il perimetro ma l'intera superficie
scolastica ecc ecc...mi sembrava ovvia come cosa e non ho pensato di
specificarla :-)




-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/MAppiaM-Mappatura-monumenti-Appia-Antica-9-11-luglio-2016-tp5876562p5878554.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] MAppiaM! Mappatura monumenti Appia Antica 9-11 luglio 2016

[Andrea Lattmann]

>in realtà non descrive un perimetro ,
>descrive un'area, un poligono.

Credo che sia stato solo un errore e che intendesse dire area.

Aury, condivido il tuo ragionamento sull' utilizzo archaeological_site che è un 
area dove all' interno ci sono reperti, perche un archaeological_site in un 
archaeological_site mi sembra molto strano. 
Purtroppo condivido anche l' idea che ci sia un disinteresse per i tesori che 
abbiamo: basti pensare che il Lombardia in provincia di Brescia, se non ricordo 
male, hanno costruito un gasdotto su una villa romana, che dopo lo scavo da 
parte degli archeologi è stata ricoperta e... Una bella colata di cemento e 
via! L' unica cosa che si può fare è mapparli, per permettere a chi interessato 
di visitarli.

Andrea Lattmann

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [talk-au] CC 4.0 was Re: Response regarding use of PSMA Administrative Boundaries (Australia)

[Cameron Shorter]

Hi all,

I've been lurking on this list for a while, work in the Australian 
spatial industry (mainly deploying open source GIS software), and am 
interested in seeing government data GNAF incorporated into OSM. What 
gets worked out with OSM will likely be used for other Australian 
datasets as well.


I expect that Government agencies won't be able to break their 
guidelines about privacy (such as sharing every address and using for 
spam), however, I expect there is more value in the GNAF datasets which 
is of value, and can be released under an OSM compatible license.


Eg: I assume GNAF has every road in Australia which would be of value to 
OSM? If so, we should put a proposal to PSMA: "Can we please have X,Y,Z 
under s OSM compatible license".


Warm regards, Cameron Shorter

On 16/07/2016 12:15 PM, cleary wrote:

I have had further contact with the Spatial Unit at the Department of
Prime Minister and Cabinet regarding the incompatibility of CC-BY and
ODbL licences.  I acknowledged their previous response but asked
politely and respectfully whether it might be possible to review the
situation in the circumstances. An interim response has been received
that it is being looked at again. If we get another refusal, then I
think that is the final answer.

In regard to the Australian Privacy Principles, I think they have
responded to our concern. On this issue, the earlier response stated
very clearly that "We can also confirm that OpenStreetMap is not
responsible for the actions of your downstream users."

The Australian Privacy Principles outline how large  organisations must
handle, use and manage personal information. Section 6 of the Privacy
Act 1988, under which the Privacy Principles are issued, defines
"personal information " as "information or an opinion about an
identified individual, or an individual who is reasonably identifiable
.. "  To the best of my knowledge, OSM does not collect or use personal
information about identifiable individuals, except those of us who are
contributors to the map or wiki and, even then, minimal information is
held and I am not aware that OSM is in any danger of breaching the
Principles. Even so, I don't think OSMF has anywhere near the $3 million
annual turnover that would make it subject to the legal requirements of
the Principles.  Google and many other corporations operating in
Australia would however be bound by the Principles, are much more
involved in collecting data about individuals, and therefore may have
more to worry about.

Data from Government sources could also be accompanied by requirements
that data not be used to commit other offences either, such as murder or
robbery. If someone used a map to plan a murder or robbery, no court
would accept a defence that the mapmaker had contributed to the crime by
publishing the map. Same with the Privacy Principles. In my opinion, the
reason that specific attention is drawn to them is that they are a
relatively new concept and privacy issues are very topical at the
moment, whereas laws about murder and robbery are better known. Further
we have the assurance from the Department of Prime Minister and Cabinet
that OSM is not responsible for the actions of downstream users.  I
don't think they could have made it any clearer.

At this stage, the discussion about Privacy Principles may be academic,
as we still await further consideration of the request for explicit
permission to use the PSMA data. If I get a favourable response, I will
submit it to the legal-talk list for their views, to make sure concerns
are addressed before we start including any data.





On Tue, Jul 12, 2016, at 06:50 PM, Simon Poole wrote:

The issues are essentially:

- we did not receive special permission to distribute the data in OSM
with attribution via the website. IMHO the permission we received for
earlier versions boiled down to allowing us to sub-license on ODbL
terms. This has now been implicitly denied. CC by 4.0 does have slightly
looser attribution requirements than previous versions, and it has been
argued that these could be fulfilled by attributing on the OSM website,
however even if that would be possible it would mean that we couldn't
sub-licence the data in question and would have to, in some form, pass
on the specific terms downstream. That is not only highly impractical,
but likely would cause a conflict with our contributor terms.

- the additional requirement to adhere to the AUS privacy regulations
was not addressed in the response, which in itself would be a killer.

As I pointed out on the legal talk mailing list, all of the above are
not issues for the usual suspects that offer proprietary data, google,
here, tomtom and so on, because they maintain tight control over their
downstream data users, but are a big issues for all projects that
produce open data and want to distribute their products on a unified
licence.

Simon



Am 11.07.2016 um 11:45 schrieb Andrew Davidson:

Is the problem CC 4.0 or is it the riders 

Re: [Talk-it] MAppiaM! Mappatura monumenti Appia Antica 9-11 luglio 2016

[Martin Koppenhoefer]

sent from a phone

> Il giorno 16 lug 2016, alle ore 20:23, Aury88  ha 
> scritto:
> 
> (archaeological_site è usato sul perimetro per indicare il sito e i dati
> comuni ai vari reperti)


in realtà non descrive un perimetro ,
 descrive un'area, un poligono.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] MAppiaM! Mappatura monumenti Appia Antica 9-11 luglio 2016

[Martin Koppenhoefer]

sent from a phone

> Il giorno 16 lug 2016, alle ore 20:23, Aury88  ha 
> scritto:
> 
> che i fori imperiali siano rovine però mi sembra evidente e che abbiano una
> connotazione storica anche...il fatto che non sia specificato cosa siano è
> un problema di completezza (mancanza di un altro tag) non di errore in se
> nel descriverli come historic=ruins


è sempre un'interpretazione, per esempio per me la basilica di massenzio è un 
archaeological site. Non fa parte del foro Romano, ma fa parte del sito 
archeologico odierno del foro Romano, si paga lo stesso ingresso, sta dietro la 
stessa recinzione ecc.

Cmq. c'è una differenza tra ruins e archaeological site, per esempio tutta Roma 
è un sito archeologico, ma non tutta Roma sono rovine. Tante chiese sono siti 
archeologici, anche se non sono rovine ecc.

historic=ruins va bene solo per le rovine (c'è qualcosa, è rotta), però di 
qualsiasi età anche moderna, mentre archaeological site è più ampio, c'è 
qualcosa oppure c'era, è rotta o anche no, oppure è stato sostituito da 
qualcosa d'altro,in ogni caso ha un valore storico.

ciao,
Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] MAppiaM! Mappatura monumenti Appia Antica 9-11 luglio 2016

[Aury88]

dieterdreist wrote
> 
> Riflettendoci sopra, in realtà non uso nemmeno troppo il tag
> archaeological
> site, perché anche questo mi sembra bello generico, preferisco dei tags
> dettagliati per i singoli reperti (al solito qualcosa historic=* e se
> proprio "rotto"/crollato forse anche ruins=yes). Per lo più uso "ruins"
> per
> cose meno significative, tipo una casetta/baita "moderna" crollata.

che è grosso modo quello che faccio io se però il tag historic=* applicato
all'elemento interno all'area archaeological_site non è esso stesso un
archaeological_site.


> infatti, il "ruins" non dice quasi niente, senno che l'oggetto è "rotto",
> tipo la rovina di una stazione ferroviaria, di una fortezza della prima
> guerra mondiale, di un castello del 1200, ma per il colosseo?

 ruins=arena o hostoric=arena ruins=yes cosa avrebbero di sbagliato?

 
> Tempo fa
> avevamo tanti "historic=ruins" sui fori imperiali, che avevano oltre un
> nome nessun altro tag (forse è ancora cosí), ma non era una situazione
> auspicabile, in quanto non c'era un livello semantico dettagliato e non
> potevi cercare cose se non con il nome (non potevi vedere quanti tempi
> c'erano per esempio). Per me "ruins" è un tag facile, un tag che dice poco
> ed utilizzandolo uno cementifica un basso livello semantico, dove in
> realtà
> sarebbe da inventare o usare dei tags più specifici. Poi, con ruins=* si
> possono aggiungere ulteriori dettagli, ma attualmente non viene fatto:

 che è proprio quello che proponevo cioè un tag a livello di ruins o di
historic, non di archaeological_site
il fatto che non sia stato usato può dipendere anche dalla ambiguità su come
mappare i singoli reperti/monumento o dal fatto che ancora nessuno ha deciso
di mappare a livello così dettagliato.
che i fori imperiali siano rovine però mi sembra evidente e che abbiano una
connotazione storica anche...il fatto che non sia specificato cosa siano è
un problema di completezza (mancanza di un altro tag) non di errore in se
nel descriverli come historic=ruins


> Quindi, se continui a taggare i monumenti antichi con ruins=* stai
> aumentando la frammentazione nel mio avviso. Non è gravissimo, tanto che
> vuole avere dei dati "completi" dovrà cercare anche nei tags poco usati...

non sono daccordo. la situazione è a mio avviso una conseguenza di come sono
i siti archeologici nel mondo e che spessissimo corrispondono a siti con un
solo elemento ritrovato (ce ne sono moltissime anche in italia, almeno in
sicilia ne ho trovate un bel po' e di cui non avevo mai sentito parlare
perchè se hai selinunte a 10km di distanza che cosa ce ne frega di un
singolo edificio in mezzo alle colline? in molte altre aree per una cosa del
genere però ci fai il sito archeologico e le visite guidate da tutta la
regione :-( ). ma situazioni più complesse possono avere stili più complessi
purchè non venga stravolto l'utilizzo dei tag già utilizzati

imho il sito archeologico è sempre stata un area al cui interno si sono
ritrovati uno o più reperti. a quel punto l'utilizzo di historic=ruins
+ruins=* o direttamente un historic=* o qualsiasi altro tag ritenuto
opportuno non mi sembra crei frammentazione, è semplicemente un livello di
mappatura più approfondito  che non duplica tag già esistenti
(archaeological_site è usato sul perimetro per indicare il sito e i dati
comuni ai vari reperti)

la frammentazione imho è quando si utilizza un tag nuovo o una nuova
combinazione di tag per indicare una cosa che ha già un tag o una
combinazione di tag dedicati a quella specifica cosa...ma se mi si usa
historic=archaeological_site sia per i siti sia per ogni o parte degli
elementi in esso contenuti onestamente mi sembra che più che di
frammentazione qui si stai facendo un tentativo di riorganizzazione e
chiarire cosa significhi questo archaeological_site ...non so se  mi
spiegoa mio avviso un sito archeologico è una cosa diversa e di livello
superiore al singolo reperto/manufatto/monumento/traccia presente
all'interno del sito.  e anche i tag per questi sarebbero semplicemente
quelli già esistenti (a parte i value mancanti per descrivere certi
elementi) quindi non c'è neanche la frammentazione per i  tag di livello
inferiore secondo me.

> -1, per modificare il wiki dovresti chiedere alla lista tagging, perché
> non
> mappiamo solo in Italia...

 quello che intendevo io era che una volta messo in chiaro cosa si
intendesse per 
archaeological_site si poteva spiegare meglio nel wiki, ma se anche solo per
questo è necessaria l'approvazione della lista tagging onestamente
passo...già non riesco a capire cosa leggo in inglese figuriamoci ad
esprimermi correttamente e a far capire un concetto che forse nel mondo
anglosassone è differente...temo di non avere al momento lo stato mentale
adeguato per affrontare una simile sfida xD
pazienza.



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/MAppiaM-Mappatura-monumenti-Appia-Antica-9-11-luglio-2016-tp5876562p5878549.html
Sent from 

Re: [Talk-at] Gemeinde-Relationen in Österreich: Abweichende Schreibweisen

[Friedrich Volkmann]

On 16.07.2016 19:43, Erwin OSM wrote:

Den Rest hatten wir wie gesagt schon in einer langen Diskussion, das
Ergebnis war, dass es in Name nichts zu suchen hat.


Da gibt es unterschiedliche Meinungen, z.B. M. Koppenhöfer (Dieterdreist) 
hat gegen das Proposal gestimmt mit der Begründung, dass es doch Teil des 
Namens sei.


Schaut euch mal die diversen ÖPNV-Relationen an ("Bus...", "Tram..."), da 
sind die Beifügungen nicht mal fürs Rendering nötig, sondern sie verbessern 
nur die Übersichtlichkeit im Editor.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-it] Suddivisioni di Roma

[Martin Koppenhoefer]

sent from a phone

> Il giorno 16 lug 2016, alle ore 19:41, Davio  ha 
> scritto:
> 
> I "quartieri" che
> compongono il distretto che poteri amministrativi hanno?


Ortsteile sono suddivisioni amministrative, anche se sono amministrati dallo 
stesso Bezirk (non ci sono elezioni al livello del Ortsteil credo) cfr:
https://de.m.wikipedia.org/wiki/Liste_der_Bezirke_und_Ortsteile_Berlins

per esempio ogni Ortsteil ha un comune (edificio / Rathaus) / uffici (Bürgeramt)

Ciao,
Martin 



___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Suddivisioni di Roma

[Davio]

Che io sappia a Berlino i distretti (adm level 9) sono entità amministrative
dove viene eletto una sorta di Sindaco di quel distretto, non i singoli
quartieri (adm level 10) che compongono quel distretto. I "quartieri" che
compongono il distretto che poteri amministrativi hanno?



-
Davide
--
View this message in context: 
http://gis.19327.n5.nabble.com/Suddivisioni-di-Roma-tp5878082p5878546.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-at] Gemeinde-Relationen in Österreich: Abweichende Schreibweisen

[Friedrich Volkmann]

On 16.07.2016 19:09, Erwin OSM wrote:

Ich kann zahlreiche offizielle Dokumente zeigen, in denen der Name von
Gemeinden festgelegt oder geändert wurde und nie der Zusatz Gemeinde oder
ähnliches im Name war!


Darum passt es super in official_name.


admin_titel wird in der Zwischenzeit zahlreich verwendet.


In dieser Falschschreibung 141 mal, und ich kann mir schon denken, wer die 
gesetzt hat. Richtig geschrieben (admin_title) kommt es 197 mal vor, und 
ebenfalls nur in Österreich. Mit diesen Zahlen werden wir keine Entwickler 
beeindrucken können. Aber du kannst ja gern mal ein Carto-Ticket anlegen und 
schauen was rauskommt.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Gemeinde-Relationen in Österreich: Abweichende Schreibweisen

[Erwin OSM]

Ich kann zahlreiche offizielle Dokumente zeigen, in denen der Name von Gemeinden festgelegt oder geändert wurde und nie der Zusatz Gemeinde oder ähnliches im Name war! 
admin_titel wird in der Zwischenzeit zahlreich verwendet.
Am 16.07.2016, 19:01, Friedrich Volkmann  schrieb:

  
On 16.07.2016 18:37, Robert Kaiser wrote:
> Dietmar schrieb:
>> * "Gemeinde Weikersdorf am Steinfelde" im Name geändert, bisher "an"
>> statt "am" und erweitert um "official_name=Weikersdorf am Steinfelde"
>> * "Gemeinde St. Corona am Wechsel" erweitert um "alt_name=Sankt Corona
>> am Wechsel"
>> * "Gemeinde Bad Deutsch Altenburg" erweitert um "official_name=Bad
>> Deutsch-Altenburg",
>> alle in Changeset [3]
>
> Ich kann mich erinnern, wir hatten mal die Debatte über das "Gemeinde" (oder
> auch "Bezirk" usw.) im name-Tag, ich bin mir nicht mehr 100% sicher, wie das
> ausging, aber ich bin noch immer der Meinung, dass es nicht da drin stehen
> sollte, sondern über andere Tags das als Gemeinde klassifiziert sein sollte.

Das ging so aus, dass ich ein Proposal für ein anderes Tag gestartet habe,
an dem sich aber keiner von euch beteiligt hat, auch nicht an der
Abstimmung, so dass es letztlich niedergestimmt wurde. Darum brauchen wir
jetzt immer noch Bezirk/Gemeinde/Katastralgemeinde im Namen, damit man sie
in der Karte auseinander halten kann. Auswertungen, wo das nicht dabeistehen
soll, können den offiziellen Namen aus official_name auslesen.

--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at
  


___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Gemeinde-Relationen in Österreich: Abweichende Schreibweisen

[Friedrich Volkmann]

On 16.07.2016 18:37, Robert Kaiser wrote:

Dietmar schrieb:

* "Gemeinde Weikersdorf am Steinfelde" im Name geändert, bisher "an"
statt "am" und erweitert um "official_name=Weikersdorf am Steinfelde"
* "Gemeinde St. Corona am Wechsel" erweitert um "alt_name=Sankt Corona
am Wechsel"
* "Gemeinde Bad Deutsch Altenburg" erweitert um "official_name=Bad
Deutsch-Altenburg",
alle in Changeset [3]


Ich kann mich erinnern, wir hatten mal die Debatte über das "Gemeinde" (oder
auch "Bezirk" usw.) im name-Tag, ich bin mir nicht mehr 100% sicher, wie das
ausging, aber ich bin noch immer der Meinung, dass es nicht da drin stehen
sollte, sondern über andere Tags das als Gemeinde klassifiziert sein sollte.


Das ging so aus, dass ich ein Proposal für ein anderes Tag gestartet habe, 
an dem sich aber keiner von euch beteiligt hat, auch nicht an der 
Abstimmung, so dass es letztlich niedergestimmt wurde. Darum brauchen wir 
jetzt immer noch Bezirk/Gemeinde/Katastralgemeinde im Namen, damit man sie 
in der Karte auseinander halten kann. Auswertungen, wo das nicht dabeistehen 
soll, können den offiziellen Namen aus official_name auslesen.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Gemeinde-Relationen in Österreich: Abweichende Schreibweisen

[Erwin OSM]

Hallo, ja die Diskussion gab es. 
Gemeinde oder Bezirk usw. gehört nicht zum Namen, das lässt sich aus den Gemeindeblättern oder entsprechenden Gemeindeerlassen entnehmen. 
Gemeinde gehört in admin_titel, genau so wie Bezirk oder Markt- und Stadtgemeinde.
Am 16.07.2016, 18:37, Robert Kaiser  schrieb:

  
Dietmar schrieb:
> * "Gemeinde Weikersdorf am Steinfelde" im Name geändert, bisher "an"
> statt "am" und erweitert um "official_name=Weikersdorf am Steinfelde"
> * "Gemeinde St. Corona am Wechsel" erweitert um "alt_name=Sankt Corona
> am Wechsel"
> * "Gemeinde Bad Deutsch Altenburg" erweitert um "official_name=Bad
> Deutsch-Altenburg",
> alle in Changeset [3]

Ich kann mich erinnern, wir hatten mal die Debatte über das "Gemeinde"
(oder auch "Bezirk" usw.) im name-Tag, ich bin mir nicht mehr 100%
sicher, wie das ausging, aber ich bin noch immer der Meinung, dass es
nicht da drin stehen sollte, sondern über andere Tags das als Gemeinde
klassifiziert sein sollte.

KaiRo

___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at
  


___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Gemeinde-Relationen in Österreich: Abweichende Schreibweisen

[Robert Kaiser]

Dietmar schrieb:

* "Gemeinde Weikersdorf am Steinfelde" im Name geändert, bisher "an"
statt "am" und erweitert um "official_name=Weikersdorf am Steinfelde"
* "Gemeinde St. Corona am Wechsel" erweitert um "alt_name=Sankt Corona
am Wechsel"
* "Gemeinde Bad Deutsch Altenburg" erweitert um "official_name=Bad
Deutsch-Altenburg",
alle in Changeset [3]


Ich kann mich erinnern, wir hatten mal die Debatte über das "Gemeinde" 
(oder auch "Bezirk" usw.) im name-Tag, ich bin mir nicht mehr 100% 
sicher, wie das ausging, aber ich bin noch immer der Meinung, dass es 
nicht da drin stehen sollte, sondern über andere Tags das als Gemeinde 
klassifiziert sein sollte.


KaiRo

___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk] MapRoulette news

[Martijn van Exel]

Hi again,

A quick MapRoulette update to announce that the new MapRoulette has now
officially replaced the old version. So if you go to http://maproulette.org/
you will see the latest version.

We added some more features and fixed some bugs over the last week as well:

* MapRoulette is now (almost) fully translatable. You can take a look at
the base English strings file[1] and commit a version for your language.
This is a new feature and not yet documented well, so if you're interested
in doing this, contact me.
* Challenges can now set their own preferences for base map layer (you can
set a custom tile layer as well), default zoom level and allowed zoom
levels. You can update your existing challenges with this information as
well.
* Each user now has a profile, where you can set some personal settings and
preferences: your preferred editor, default base map layer (or custom tile
URL), your locale / language and a UI color preference.

No new challenges to report, but I hope some new ideas will pop up soon! If
you do not know how to create a new Challenge, please see the tutorial (or
ask me for help).

[1] https://github.com/maproulette/maproulette2/blob/master/conf/messages
[2]
https://github.com/maproulette/maproulette2/wiki/Introducing-New-MapRoulette---Part-1.-Creating-and-Maintaining-Challenges

Martijn van Exel
http://mvexel.github.io/

On Sat, Jul 9, 2016 at 3:37 PM, Martijn van Exel  wrote:

> Hi all,
>
> Another update on MapRoulette progress. I am getting ready to retire the
> old MapRoulette, which is still live on maproulette.org. The new version,
> which is now at http://maproulette.org:8080/ will move to
> http://maproulette.org/.
>
> If you are a Challenge author on the old MapRoulette, and you want your
> challenge to live on, please check out the Challenge creation tutorial[1]
> and re-create your challenge on the new version. Please let me know if you
> need help.
>
> Some of the latest changes in the recent beta are:
> * Home page now shows challenges as centroid points
> * Search enhanced with keywords (see [2] for details)
> * Challenge authors can make their own Projects visible
> * Metrics per challenge on Metrics page
>
> Still coming (soon):
> * More improvements to search
> * Personal settings (base tile layer, default editor and more)
> * Per-Challenge settings (default zoom level, tile layer, perhaps more)
>
> If you want to start creating your own Challenges right away, please see
> the tutorial[1]. I will also be giving a workshop on how to do this at SOTM
> US and (hopefully) also at SOTM in Brussels.
>
> Some new Challenges that have recently been added by mappers like you:
> * Look at FIXMEs in Argentina: http://maproulette.org:8080/map/234/
> * Add Sidewalks to major roads in San Francisco, USA:
> http://maproulette.org:8080/map/228/
> * Add Helipads to hospitals worldwide:
> http://maproulette.org:8080/map/227/
>
> Lastly, if you read this on talk@ (sorry for xposting) and are interested
> in MapRoulette, I recommend to also subscribe to
> maproule...@openstreetmap.org
>
> [1]
> https://github.com/maproulette/maproulette2/wiki/Introducing-New-MapRoulette---Part-1.-Creating-and-Maintaining-Challenges
>
> [2]
> https://github.com/maproulette/maproulette2/wiki/Introducing-New-MapRoulette-Part-2.-Discovering-MapRoulette-Challenges
>
> Martijn van Exel
> http://mvexel.github.io/
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Come di tagga ufficio/magazzino ditta di spurgo pozzi neri

[Martin Koppenhoefer]

sent from a phone

Il giorno 16 lug 2016, alle ore 14:00, Damjan Gerl  ha 
scritto:

>> non è vietato in tutta la CE dal 2015 usare i pozzi neri senza purificazione 
>> biologica?
> 
> Non saprei, io per esempio a casa ho ancora il pozzo nero...


scusa, non sono vietati se sono chiusi e vengono spurgati, sono vietati quelli 
con scolo (dentro un fiume/torrente)

ciao,
Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] Skandal! Skulptur im Park ohne rollstuhlgerechte Toilette!

[Tobias]

Zu 3.

Tags für behinderten gerechte k
Wcs können nur an schon ‎in osm vorhandene Toiletten angebracht werden.

Gruß


  Originalnachricht  
Von: Holger Dieterich
Gesendet: Samstag, 16. Juli 2016 14:42
An: talk-de@openstreetmap.org
Antwort an: Openstreetmap allgemeines in Deutsch
Betreff: [Talk-de] Skandal! Skulptur im Park ohne rollstuhlgerechte Toilette!


Hallo talk-de,

ich heiße auch Holger, bin Mitgründer von Wheelmap und habe außerdem
das Proposal "toilets:wheelchair"[1] gestellt damals.


   - Ich bin nach wie vor überzeugt dass "unknown"-tags quatsch sind
und kann nicht nachvollziehen woher die kommen.
   - "wheelchair_toilet" war ein Bug in unserer Android App, der wie
gesagt schon lange behoben ist. Ich bin auch für einen mechanischen
Edit wie von Tom vorgeschlagen (s.u.)


Wegen Orten bei denen man keine Toilette erwartet:

Tatsächlich haben wir in den Wheelmap-Apps (Web, iOS, Android und
Windows10) den tag toilets:wheelchair einheitlich eingebaut und machen
keine Fallunterscheidung. Offenbar markieren manche App-User daher so
etwas statt es einfach unmarkiert zu lassen.

Ideen wie wir das lösen könnten:


   1. Alle Apps so ändern, dass nur bei bestimmten Ortstypen "toilets"
angezeigt wird und verändert werden kann (kann man das klar
entscheiden z.B: bei Denkmälern o.ä.? Ein eListe aller Ortstypen die
von Wheelmap verwendet werden findet ihr hier:
http://wheelmap.org/node_types ) ODER
   2. Im "toilets"-Dropdown von allen Wheelmap-Apps eine Option
hinzufügen "nicht vorhanden" was nicht in OSM geschrieben wird.
   3. Weitere Ideen?


Übrigens:
Das Wheelmap Backend und alle unsere Apps sind übrigens open source,
wir freuen uns über Feedback und Beitragende:
https://github.com/sozialhelden .
Trotzdem investieren natürlich weiterhin selbst in die Entwicklung von
Wheelmap und haben für Backend und die Apps zwei Agenturen die wir
regelmäßig beauftragen.


Grüße,

Holger

[1] http://wiki.openstreetmap.org/wiki/Proposed_features/toilets:wheelchair



Holger Jeromin wrote on 2016/07/09 08:19:
* Tom Pfeifer > Wrote in message:

*>>* Dazu kommt noch ein neuer Tag 'wheelchair_toilet=*' (4600x), hier
gibt es mehr
*>>* 'unknown' als 'yes' und 'no' zusammen (53%). Undokumentiert.
*>>* Das falsche Tag war mir auch schon mal aufgefallen und habe es den
*>*   sozialhelden gemeldet. Daraufhin haben sie den Fehler im backend
*>*   innerhalb von wenigen Tagen behoben. Das ganze ist ein zwei Jahre
*>*   her.
*>>* Neue sollten nicht mehr rein kommen. Ich wäre für einen mechanical
*>*   edit zur Korrektur.
*
Danke Holger für den Hinweis, ich habe daraufhin mal das Zeitverhalten
analysiert:

Über den Sammeluser 'wheelmap_android' kamen noch bis vor 7 Monaten
die 'wheelchair_toilet' herein. In jüngeren Changesets nicht mehr,
allerdings wird dann zusätzlich ein 'toilets:wheelchair' aufgeklebt,
ohne das alte zu löschen.

'unknown'-Werte sind mir in jüngeren Changesets auch nicht mehr aufgefallen.
Leider sieht man den Fix nicht an der Softwareversion, alt wie neu kommt mit
'rosemary v0.4.4'.

Für einen mechanischen Edit wäre ich auch, insbesondere da der fehlerhafte
Key nun auch von anderen Mappern übernommen wird.

Kriterien wären aus meiner Sicht:
- Löschen von {wheelchair_toilet|toilets:wheelchair}=unknown
- Wenn beide vorhanden sind, vergleichen, bei Gleichheit
wheelchair_toilet löschen
- bei Ungleichheit die Anzahl ermitteln, ob man sich die einzeln  
ansehen kann,

   ggf. den zeitlich neueren Wert übernehmen, meist wird das
toilets:wheelchair sein
- wenn nur wheelchair_toilet={yes|no} vorhanden, auf  
toilets:wheelchair ändern

- verbleibende Werte ausserhalb von {yes|no} manuell prüfen.

Unschön bleiben noch das mehrfache Hochzählen der Versionsnummern im
gleichen CS für jeden geänderten Tag, und das *toilet*=no an Objekten,
an denen man ohnehin keine Toilette erwartet, z.B.

amenity=drinking_water
highway=bus_stop
natural=cave_entrance
historic=memorial
tourism=artwork

tom
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de





___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Skandal! Skulptur im Park ohne rollstuhlgerechte Toilette!

[Michael Reichert]

Hallo Holger,

Am 16.07.2016 um 14:42 schrieb Holger Dieterich:
> Wegen Orten bei denen man keine Toilette erwartet:
> 
> Tatsächlich haben wir in den Wheelmap-Apps (Web, iOS, Android und
> Windows10) den tag toilets:wheelchair einheitlich eingebaut und machen
> keine Fallunterscheidung. Offenbar markieren manche App-User daher so
> etwas statt es einfach unmarkiert zu lassen.
> 
> Ideen wie wir das lösen könnten:
> 
> 
>1. Alle Apps so ändern, dass nur bei bestimmten Ortstypen "toilets"
> angezeigt wird und verändert werden kann (kann man das klar
> entscheiden z.B: bei Denkmälern o.ä.? Ein eListe aller Ortstypen die
> von Wheelmap verwendet werden findet ihr hier:
> http://wheelmap.org/node_types ) ODER
>2. Im "toilets"-Dropdown von allen Wheelmap-Apps eine Option
> hinzufügen "nicht vorhanden" was nicht in OSM geschrieben wird.
>3. Weitere Ideen?

Es kommt bei manchen Objekten auf die Größe an, ob sie eine Toilette
haben oder nicht. Ein kleines Denkmal hat gewöhnlicherweise keine
Toilette (für Nicht-Behinderte). Dort ist toilets:wheelchair=no sinnlos.
Wenn es jedoch ein große Denkmal ist und Eintritt verlangt wird, ist oft
auch eine Toilette vorhanden. Dann ist es in Ordnung, dass
toilets:wheelchair=yes/no gemappt wird. Ähnlich ist es mit Parkplätzen.

Daher fände ich Option 2 besser. Dabei reicht es IMHO aus, einfach über
die OSM-ID die Verknüpfung zwischen eurer eigenen Datenhaltung und den
OSM-Daten zu machen. OSM-IDs sind zwar nicht ganz statisch, aber für
euren Anwendungsfall genügt es, wenn man sie als statisch betrachtet.
Wenn es keine Toiletten gibt, dann braucht man kein toilets:wheelchair=*
in OSM.

Viele Grüße

Michael


-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[OSM-talk-nl] Null Island

[Pander OpenTaal]

Null Island

http://m.slashdot.org/story/313717

-- 
Stichting OpenTaal
http://opentaal.org
http://twitter.com/opentaal

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

[Talk-de] Skandal! Skulptur im Park ohne rollstuhlgerechte Toilette!

[Holger Dieterich]

Hallo talk-de,

ich heiße auch Holger, bin Mitgründer von Wheelmap und habe außerdem
das Proposal "toilets:wheelchair"[1] gestellt damals.


   - Ich bin nach wie vor überzeugt dass "unknown"-tags quatsch sind
und kann nicht nachvollziehen woher die kommen.
   - "wheelchair_toilet" war ein Bug in unserer Android App, der wie
gesagt schon lange behoben ist. Ich bin auch für einen mechanischen
Edit wie von Tom vorgeschlagen (s.u.)


Wegen Orten bei denen man keine Toilette erwartet:

Tatsächlich haben wir in den Wheelmap-Apps (Web, iOS, Android und
Windows10) den tag toilets:wheelchair einheitlich eingebaut und machen
keine Fallunterscheidung. Offenbar markieren manche App-User daher so
etwas statt es einfach unmarkiert zu lassen.

Ideen wie wir das lösen könnten:


   1. Alle Apps so ändern, dass nur bei bestimmten Ortstypen "toilets"
angezeigt wird und verändert werden kann (kann man das klar
entscheiden z.B: bei Denkmälern o.ä.? Ein eListe aller Ortstypen die
von Wheelmap verwendet werden findet ihr hier:
http://wheelmap.org/node_types ) ODER
   2. Im "toilets"-Dropdown von allen Wheelmap-Apps eine Option
hinzufügen "nicht vorhanden" was nicht in OSM geschrieben wird.
   3. Weitere Ideen?


Übrigens:
Das Wheelmap Backend und alle unsere Apps sind übrigens open source,
wir freuen uns über Feedback und Beitragende:
https://github.com/sozialhelden .
Trotzdem investieren natürlich weiterhin selbst in die Entwicklung von
Wheelmap und haben für Backend und die Apps zwei Agenturen die wir
regelmäßig beauftragen.


Grüße,

Holger

[1] http://wiki.openstreetmap.org/wiki/Proposed_features/toilets:wheelchair



Holger Jeromin wrote on 2016/07/09 08:19:
>* Tom Pfeifer > Wrote in message:
*>>* Dazu kommt noch ein neuer Tag 'wheelchair_toilet=*' (4600x), hier
gibt es mehr
*>>* 'unknown' als 'yes' und 'no' zusammen (53%). Undokumentiert.
*>>* Das falsche Tag war mir auch schon mal aufgefallen und habe es den
*>*   sozialhelden gemeldet. Daraufhin haben sie den Fehler im backend
*>*   innerhalb von wenigen Tagen behoben. Das ganze ist ein zwei Jahre
*>*   her.
*>>* Neue sollten nicht mehr rein kommen. Ich wäre für einen mechanical
*>*   edit zur Korrektur.
*
Danke Holger für den Hinweis, ich habe daraufhin mal das Zeitverhalten
analysiert:

Über den Sammeluser 'wheelmap_android' kamen noch bis vor 7 Monaten
die 'wheelchair_toilet' herein. In jüngeren Changesets nicht mehr,
allerdings wird dann zusätzlich ein 'toilets:wheelchair' aufgeklebt,
ohne das alte zu löschen.

'unknown'-Werte sind mir in jüngeren Changesets auch nicht mehr aufgefallen.
Leider sieht man den Fix nicht an der Softwareversion, alt wie neu kommt mit
'rosemary v0.4.4'.

Für einen mechanischen Edit wäre ich auch, insbesondere da der fehlerhafte
Key nun auch von anderen Mappern übernommen wird.

Kriterien wären aus meiner Sicht:
- Löschen von {wheelchair_toilet|toilets:wheelchair}=unknown
- Wenn beide vorhanden sind, vergleichen, bei Gleichheit
wheelchair_toilet löschen
- bei Ungleichheit die Anzahl ermitteln, ob man sich die einzeln ansehen kann,
   ggf. den zeitlich neueren Wert übernehmen, meist wird das
toilets:wheelchair sein
- wenn nur wheelchair_toilet={yes|no} vorhanden, auf toilets:wheelchair ändern
- verbleibende Werte ausserhalb von {yes|no} manuell prüfen.

Unschön bleiben noch das mehrfache Hochzählen der Versionsnummern im
gleichen CS für jeden geänderten Tag, und das *toilet*=no an Objekten,
an denen man ohnehin keine Toilette erwartet, z.B.

amenity=drinking_water
highway=bus_stop
natural=cave_entrance
historic=memorial
tourism=artwork

tom
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[LeTopographeFou]

Jean-Yvon,

Message reçu, je regarde en Europe et fais une synthèse.

Cdt,

LeTopographeFou

Le 14/07/2016 00:12, osm.sanspourr...@spamgourmet.com a écrit :


Oui un exemple *aux États-Unis*.

Je préfèrerais des exemples probants en Europe car leurs méthodes 
comme je l'ai déjà dit, ce n'est pas forcément une référence.


On voit d'ailleurs comme tu le dis toi-même is_in:state 
.


Philippe, les panneaux indiquent Tartempion en direction, pas D234.

Et quand tu vois un panneau de direction vers D234, c'est que tu n'es 
pas sur la D234.
Le routage ne se fait pas par des noms de routes mais par des gabarits 
de voirie. Comme déjà dit sur ce long fil de discussion.
Si tu veux un Paris-Brest (ce n'est pas qu'un gâteau) en passant par 
les anciennes N12 devenues départementales... et le nom ce n'est pas 
le Dx12... Franchement plus j'y pense et plus je pense que c'est plus 
nuisible qu'utile (je ne vois pas l'usage et pourtant j'emprunte des 
départementales qu'on nommera "ancienne route de" (la voie express 
étant devenue la voie normale)).


Jean-Yvon


Le 13/07/2016 à 23:16, LeTopographeFou - letopographe...@gmail.com a 
écrit :
Et là je ferais mieux de sortir un exemple sur lequel je n'ai pas 
fait de modification (dsl pour le spam) :

http://www.openstreetmap.org/relation/1502491
LeTopographeFou




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Come di tagga ufficio/magazzino ditta di spurgo pozzi neri

[Damjan Gerl]

15.07.2016 - 19:49 - Martin Koppenhoefer:


2016-07-15 17:05 GMT+02:00 Damjan Gerl >:


Come da oggetto: come si potrebbe taggare una ditta di spurghi? Ho
cercato in wiki ma non ho trovato niente di simile. L'unica cosa
che ho trovato e come taggare il pozzo nero man_made=septic_tank



non è vietato in tutta la CE dal 2015 usare i pozzi neri senza 
purificazione biologica?


Non saprei, io per esempio a casa ho ancora il pozzo nero...



Forse craft=sewage_disposal? shop=sewage_disposal? Chiederei anche in 
lista "tagging"

altre parole forse pertinenti: sewage sludge, slurry

Ciao,
Martin


Grazie
proverò a cercare ancora qualcosa.

Damjan

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-ht] Recrutement d'enqueteurs et autre qualificatifs

[Louino Robillard]

Mwen dako,
E mwen salye devouman nou.

Men li tre enpotan pou nou pa fe pou yo, men fe ak yo.

Yo se yon gwoup, si yo genyen regleman enten yo fok moun ki ap vini ede yo
respekte regleman yo.

Kek fwa ou konn pase ou ap ede epi se fos ou wap pedi fok moun ou gwoup wap
ede konsyans li bezwen ed pouw ede li.

Mwen toujou la pou mwen preche konbit, pou mwen preche tet ansanm, men
ansanm travay ansanm. Men mwen konnen tou tout sa yo paka fe fet nan deze.

Mwen di tout sa pou mwen fe nou konnen,
Se nan konpreyasyon, chita pale, chita tande , youn ap rive konprann lot.

Mwen se gwo fanatik COSMHANNE depi nan kreyasyon gwoup sa, mwen vle we yo
rete aktiv, mwen ap disponib pou kelkeswa konsey wap bezwen.

Men franchman, mwen pap janm ka plis renmen gwoup la ke jen limonad yo, ke
jen nan depatman Nord yo. Paske se pitit yo, se lakay yo.

Nou ka toujou ankouraje yo, men pa pouse yo twop, pa antre nan mita
enstitisyon yo san yo pa envite nou.

Fok fwa ou konn vle ede,
Men fomil ke ou anplwaye fe ou fe plis domaj. Konsey pou ou Samuel ak Billy.

Mwen kontan we nap chache opotinite poste pou jeunes yo se tre byen, mwen
renmen sa.
Se youn ki pou sitni lot. Youn chache pou lot, youn fome lot, youn emfome
lot. Youn chache konprann lot, youn tande lot 
Se konsa nap rive atenn objektiv nou kisa viv ansanm, viv byen ansanm.

Ann kontinye fe konbit,
Robi
On Jul 16, 2016 6:15 AM, "ALCE, Samuel Paul" 
wrote:

> Tout otan nap viv, Nap tj eseye rasanble moun, si yo pa vle rasanble nap
> toujou aranje nou pou nou fe KONBIT ak yo, pou nou ede yo, menm si se
> pandan yo degrennen yon nou 2 ou 3 ap deside regwoupe kanmenm
>
> Malgre yo gen lide ke nap vyole CHARTE yo, nou pap sispann pataje ak yo,
> chache pou yo, pote pou yo, fòme yo pou juskaske nou fe yo konnen kisa ki
> KONBIT...
>
> Nou ka pa reyisi jodia, nou ka pa reyisi demen, men ti kras pa ti kras nou
> va rasanble yon jou.. . ak menm lide, ak menm anvi, sou menm tab fratènite
> a poun fè bon jan KONBIT.
>
> Al postile sou link sa pou nou jwenn opotinite pa nou... DAYÈ SE SA NOU
> CHAK AP CHACHE. Nou wè ke pwop tèt nou
>
> Men lè na deside fè KOMBIT na va gen posibilite pou nou kreye pwop zafe pa
> nou.
>
> Fok chenn mantal la kase, fok esklavaj mantal la fini...
>
>
>
> ALCE Samuel Paul,
>
> Port-au-Prince, Haiti
>
> Field Data Coordinator @ DAI / USAID
> Géo-Information Specialist (GIS)
> Humanitarian OpenStreetMap Team member
> OpenStreetMap contributor in Haiti
>
> OSM username: ALCE Samuel Paul
>
> Cell: (509) 4894-2175 / 4638-4875 / 4289-7651
>
>
> Skype: samuelalce
> Whatsapp: (509) 4289-7651
> On Jul 16, 2016 04:54, "Louino Robillard" 
> wrote:
>
>> Ann kontinye fe konbit.
>>
>> *Konbit pa vle di pou w pa travay pou entere pwop tet paw, men konbit la
>> vle di mete ak lot moun, ansanm pou travay pou entere nou.
>>
>> Se nan konbit fos nou chache.
>> Yon sel dwet pa manje kalalou.
>> 1=1
>> Men 1+1=2
>>
>> Ann kontinye fe konbit
>> Robi.
>> On Jul 15, 2016 3:27 PM, "ALCE, Samuel Paul" 
>> wrote:
>>
>> Lots of respect Jean Bully Prophete... One of the good ones!
>> Mwen sur ke Bully se youn nan bon yo
>> NAP BATAY POU KONBIT LA FET E NAP KONTINYE FE KONBIT NOU PAP LACHE
>> MENM SI YO PANSE NAP BATAY POU ENTERE PA NOU...
>> Robi mwen salye sou track sa...
>>
>> KONBIT PI RED
>>
>>
>>
>>
>>
>> Le 15 juillet 2016 à 16:18, Jean Bully PROPHETE  a
>> écrit :
>>
>> > Veuillez aller sur ce lien et appliquez pour votre qualificatif:
>> > offre d'emploi 
>> > A tous les membres de COSMHANNE c'est un des points que je voulais vous
>> > parler alors tentez votre chance, ceci pourrait etre beaucoup plus
>> formel
>> > cependant je ne voulais pas continuer a violer votre charte.
>> >
>> > Merci
>> >
>> > --
>> > * Jean Bully Prophete*
>> > GIS Field Agent at DAI/AVANSE Haiti
>> > Humanitarian OpenstreetMap Team member / OSM Advanced Mapper-Trainer
>> > 
>> > Skype:jeanbully
>> > Linkedin: Jean Bully
>> > <
>> >
>> https://www.linkedin.com/profile/view?id=AAIAAAsyuO8B57pdiqGkMfBwnWlmW99xXTaOhVU=nav_responsive_tab_profile_pic
>> > >
>> > Phone/Whatsapp:+1(509)3732-2379
>> > ___
>> > Talk-ht mailing list
>> > Talk-ht@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-ht
>> > Notez! Vous pouvez utiliser Google Translate (
>> http://translate.google.com)
>> > pour traduire les messages.
>>
>>
>>
>>
>> --
>> *ALCE Samuel Paul, *
>>
>> *Port-au-Prince, Haiti *
>>
>> *Field Data Coordinator @ DAI / USAID*
>> *Géo-Information Specialist (GIS)*
>>
>> *Humanitarian OpenStreetMap Team memberOpenStreetMap** contributor in
>> Haiti *
>>
>> *OSM username: ALCE Samuel Paul *
>>
>> *Cell**: (509) 4894-2175 / 4638-4875 / 4289-7651
>>
>>  *
>> *Skype**: samuelalce*
>> *Whatsapp*: *(509) **4289-7651*
>> 

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[LeTopographeFou]

Merci François pour cette liste.

Mes commentaires dans ton mail.

Mais j'ai deux questions :

 * La liste de diffusion est bien pour discuter mais pas pour avoir une
   vue d'ensemble. Y a-t-il un media plus approprié ? Le wiki ?
 * Tout n'a surement pas encore été dit mais un jour il faudra se
   décider sinon on pourra discuter pendant longtemps :-) . Quel est le
   process pour à la fin aboutir à une décision équilibrée et
   représentative ?

Cdt,

LeTopographeFou

Le 14/07/2016 14:16, François Lacombe a écrit :


[Envoyé depuis un téléphone]

Bonjour a tous,

En effet discussion passionnante, pas assez de temps pour y participer 
pleinement cette semaine


Le 14 juil. 2016 11:32 AM, "Christian Quest" > a écrit :
> Oui, c'est un peu le problème... se focaliser sur le "comment" alors 
qu'il n'y a pas de consensus sur le "pourquoi", c'est à dire sur 
l'utilité même de ces relations.

>
> Si un consensus est trouvé sur l'utilité, on pourra passer au 
"comment". Là on met la charrue avant les boeufs.


Sous cet angle, d'accord avec toi

>
> Donc... quels avantages/inconvénients pour ces relations ?

De ce que j'ai retenu de l'échange :
CONTRE :
* Une relation complexifierait l'accès a l'information et la contribution

C'est indéniable vue que le premier moyen d'accès utilisé est 
généralement la Way. Mais sans pour autant en faire un avantage cela 
simplifie aussi car :


 * cela permet de dissocier ce qui est de "la route" de ce qui est de
   "la départementale". La liste des attributs de la route n'en sera
   que plus claire. De même pour la RD.
 * plus tôt un utilisateur découvre les relations plus vite il se
   structurera dans le modèle OSM (et moins il prendra d'habitude
   malheureuse).
 * plus le concept de relation est structurant plus les outils
   s'améliorent pour rendre transparente la chose. Ex de la plupart des
   outils qui, quand on scinde une way, mettent à jour les relations
   avec les rôles qui vont bien.

* Les relation seraient difficilement maintenables (a mettre en 
perspective avec la dispo et fonctionnalités des outils)



Cf. point précédent.
Je ne vois pas en quoi regrouper certaines infos rend les choses moins 
maintenables. Cela les rend plus accessibles et synchronisées.
De plus, dans la proposition actuelle où le tag ref restent dans la way 
et que l'on créé une relation, c'est même un très bon moyen de détecter 
une incohérence (Osmose, validation JOSM...). Alors que si on a que le 
ref... et bien bon courage pour détecter !


* Dans le cas ou on a plusieurs relations RD, transport en commun, iti 
bis qui impliquent le même tronçon de route, le consommateur peut 
avoir plus de travail pour faire le lien "la ligne de bus Y emprunte 
une partie de la RD X". Quoi que des outils (osm2pgsql) peuvent 
largement aider dans cette tache de formatage pour un usage particulier.



Tant que le tag ref est conservé cela ne change rien il me semble.


POUR :

* Le modèle proposé est déjà utilisé dans d'autres pays et fait l'objet 
d'une documentation sur le Wiki (statut "in use"). 115807 relations 
route=road de par le monde, soit 27 % des relations de type route ! 
route=bus n'occupe que la seconde place (retirer les relations RD que 
j'ai créé a un effet négligeable sur ces chiffres).


Ce point est non négligeable ;-) .


* Les relations permettraient l'unicité de certaines infos (référence 
Dxx, iti E...) et séparerait l'empruntant de l'emprunté.
Ainsi un tronçon de route restant un tronçon de route, il pourrait 
être utilisé indépendamment dans plusieurs relations différentes (RD, 
iti bis, convois exceptionnels, transports en commun et d'autres que 
je n'imagine pas)


Oui, c'est une histoire de sémantique. Une route empruntée peut avoir 
une propriété différente (ou inexistante) que la RD.


* Selon le format de la relation, on obtiendrait une visibilité plus 
claire d'un itinéraire, en reliant explicitement les tronçons impliqués


* Enfin, la relation peut regrouper les objets périphériques avec un 
rôle spécifique (bornage, panneaux, boucles de comptage)


En effet, les bornes kilométriques sont spécifiques à la RD, pas à la 
route qu'emprunte la RD ni à la route qui passe en parallèle à côté.


Cette liste peut être complétée au besoin, désolé d'avance pour tout 
oubli involontaire ou formulation maladroite


François



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] MAppiaM! Mappatura monumenti Appia Antica 9-11 luglio 2016

[Martin Koppenhoefer]

2016-07-16 12:41 GMT+02:00 Aury88 :

> io fino ad oggi ho sempre preferito estendere archaeological_site all'area
> del sito archeologico che, comprendendo così di solito più tipologie di
> elementi, non usavo per indicare i singoli tipi di reperto/monumento ma
> semplicemente la tipologia generica (se possibile), il periodo e la civiltà
> dei reperti all'interno del sito. non ho mai messo un archaeological_site
> dentro un altro onestamente ritenendo il tag ruins=tipo_di_elemento
> sufficiente per la descrizione appunto dei vari elementi all'interno del
> sito...
>




>
> mi spiace, ma come stile il mettere un archaeological_site dentro l'altro
> non mi convince perchè  si userebbe lo stesso tag sia per indicare i
> reperti, sia per indicare il "confine" di un area archeologica che contiene
> anche cose che non sono reperti (cestini, panchine, strade, servizi,
> biglietteria, lampioni), almeno nel mio caso per come utilizzo
> solitamente il tag archaeological_site uscirebbe una cosa del genere.
>



anch'io uso il tag archaeological site sul "sito", non lo uso per un vaso o
per una colonna, per una casetta invece forse si. Non metto "lo stesso
tag", perché mi impegno di mettere anche un site_type. Avere più siti uno
dentro l'altro non mi sembra un problema, lo facciamo anche con altri tags,
per esempio "place".
Riflettendoci sopra, in realtà non uso nemmeno troppo il tag archaeological
site, perché anche questo mi sembra bello generico, preferisco dei tags
dettagliati per i singoli reperti (al solito qualcosa historic=* e se
proprio "rotto"/crollato forse anche ruins=yes). Per lo più uso "ruins" per
cose meno significative, tipo una casetta/baita "moderna" crollata.



>
> effettivamente il mio stile potrebbe non andare bene per indicare altri
> tipi
> di elementi che non siano rovine, ma secondo me con il Lifecycle prefix si
> potrebbe riuscire a sopperire alle mancanze del mio metodo...
>


infatti, il "ruins" non dice quasi niente, senno che l'oggetto è "rotto",
tipo la rovina di una stazione ferroviaria, di una fortezza della prima
guerra mondiale, di un castello del 1200, ma per il colosseo? Tempo fa
avevamo tanti "historic=ruins" sui fori imperiali, che avevano oltre un
nome nessun altro tag (forse è ancora cosí), ma non era una situazione
auspicabile, in quanto non c'era un livello semantico dettagliato e non
potevi cercare cose se non con il nome (non potevi vedere quanti tempi
c'erano per esempio). Per me "ruins" è un tag facile, un tag che dice poco
ed utilizzandolo uno cementifica un basso livello semantico, dove in realtà
sarebbe da inventare o usare dei tags più specifici. Poi, con ruins=* si
possono aggiungere ulteriori dettagli, ma attualmente non viene fatto:

historic=ruins   68160
di cui hanno il tag "historic:civilization": non compare

ruins!=yes & ruins!=no   1783
di cui hanno il tag "historic:civilization": 354

poi se guardi questi valori, i più usati sono (in ordine):
castle 311
church 175
temple 101
building 94
bunker 87
Città 64
farm 64
tower 53
theatre 46
railroad 41
house 36
fort 32
wall 32
monastery
chapel
blackhouse
hut
e una coda lunga con non più di 20 occorrenze.

gli unici di questi che _potrebbero_ avere legami al mondo antico sono:
temple, città, farm, tower, theatre, house, fort, wall


Invece di site_type ci sono 20185
con historic:civilization   1328

Oppure di historic=archaeological_site  44806
con site_type   17903


Quindi, se continui a taggare i monumenti antichi con ruins=* stai
aumentando la frammentazione nel mio avviso. Non è gravissimo, tanto che
vuole avere dei dati "completi" dovrà cercare anche nei tags poco usati...



>
> decidiamo per bene come fare e appena potrò mi metto a modificare il wiki
> in
> base a cosa viene deciso :-)
>


-1, per modificare il wiki dovresti chiedere alla lista tagging, perché non
mappiamo solo in Italia...

Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-at] Gemeinde-Relationen in Österreich: Abweichende Schreibweisen

[Dietmar]

Hallo,

ich habe in meiner Hausnummerauswertung auf regio-osm.de endlich mal
geprüft, welche österreichischen Gemeinden ich noch nicht auswerte, weil
der Name in OSM zu unterschiedlich ist im Vergleich zu der Schreibweise
von [1] (bisher noch 2014er Version).

Gemeindeveränderungen habe ich natürlich bei mir lokal durchgeführt.

Übrig geblieben sind noch unten aufgeführte Gemeinden, davon habe ich 8
selbst in OSM angepasst, nach Recherche auf den amtlichen
Gemeindewebsites. Je nach dortiger Schreibweise habe ich die
Schreibweisen in alt_name (nur ausgeschriebene Namen, meist St. nach
Sankt) oder in official_name, wenn der Name so auf der Gemeindewebsite
und auf Statistika Austria übereinstimmend anders geschrieben wurden.

Ich habe nach den ersten 8 Änderungen aber aufgehört, weil ich die
Änderungen doch lieber der österreichischen Community überlassen möchte.

Hier die 8 Änderungen in 3 Changesets von heute. Wenn Ihr die Änderungen
als unangemessen empfindet, könnt Ihr die Änderungen revertieren oder im
einzelnen anpassen.

* "St. Leonhard im Pitztal" erweitert um "alt_name=Sankt Leonhard im
Pitztal" in Changeset [2],

* "Gemeinde Weikersdorf am Steinfelde" im Name geändert, bisher "an"
statt "am" und erweitert um "official_name=Weikersdorf am Steinfelde"
* "Gemeinde St. Corona am Wechsel" erweitert um "alt_name=Sankt Corona
am Wechsel"
* "Gemeinde Bad Deutsch Altenburg" erweitert um "official_name=Bad
Deutsch-Altenburg",
alle in Changeset [3]

* "St.Stefan ob Stainz" erweitert um "alt_name=Sankt Stefan ob Stainz"
* "St.Josef (Weststeiermark)" erweitert um "alt_name=Sankt Josef
(Weststeiermark)"
* "Kalsdorf" erweitert um "official_name=Kalsdorf bei Graz"
* "Groß St.Florian" erweitert um "official_name=Groß Sankt Florian"
alle in Changeset [4]



Außerdem habe ich einen vermutlichen Fehler gefunden bei
* "Sankt Johann am Walde" [5] wurde am 14.01.2016 in "Mati" umgenannt,
das ist auf Wikipedia nicht nachvollziehbar.
In diesem Fall habe ich nur einen Changeset-Kommentar hinterlassen.


Für die folgenden Gemeinden sind noch Unterschiede vorhanden, ich möchte
die Änderungen aber nicht mehr selbst durchführen, es sei denn, die
österreichische Community gibt mir grünes Licht für die Änderungen, wie
ich sie oben für die durchführten 8 Fälle gemacht habe.


GKZ-Id   Gemeindename gemäß Statistika Austria
==
60642   Sankt Radegund bei Graz
60668   Sankt Marein bei Graz
61032   Sankt Johann im Saggautal
61056   Sankt Veit in der Südsteiermark
61114   Sankt Peter-Freienstein
61115   Sankt Stefan ob Leoben
61425   Sankt Peter am Kammersberg
61439   Neumarkt in der Steiermark
61442   Sankt Georgen am Kreischberg
61443   Sankt Lambrecht
61621   Sankt Martin am Wöllmißberg
61633   Söding-Sankt Johann
61744   Sankt Kathrein am Hauenstein
61745   Sankt Kathrein am Offenegg
61746   Sankt Margarethen an der Raab
62026   Sankt Georgen ob Judenburg
62032   Sankt Peter ob Judenburg
62046   Sankt Margarethen bei Knittelfeld
62242   Sankt Jakob im Walde
62381   Kirchbach in der Steiermark

Ich werde in den nächsten Tagen meine lokalen Prüfungen wiederholen.
Dann würden Änderungen bis dahin im OSM-Bestand vermutlich zu weiteren
Auswertungen führen.


viele Grüße

Dietmar aka okilimu
regio-osm.de Admin



[1]
http://www.statistik.at/web_de/klassifikationen/regionale_gliederungen/gemeinden/
[2] https://www.openstreetmap.org/changeset/40776009
[3] https://www.openstreetmap.org/changeset/40776506
[4] https://www.openstreetmap.org/changeset/40776654
[5] https://www.openstreetmap.org/relation/410395

___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-cz] Fwd: Re: edity z maps.me

[Karel Volný]

Dne So 16. července 2016 12:35:16, Karel Volný napsal(a):
> zdar,
> 
> > Obavam se, ze to bude cim dal horsi, prave koukam ze tam je cim dal vic
> > pokusu o zverejnovani jakesy reklamy. Zacinam mit dojem, ze nejlepsi
> > reseni by bylo bot, ktery to bude vse rovnou mazat.
> > 
> > http://www.openstreetmap.org/note/629304
> > 
> > A naprosto nejhorsi na tom je prave to, ze to nacpou i rovnou do mapy.
> 
> tož zase toto konkrétně ale až tak špatně nedopadlo, až na ten shop=outdoor
> 
> ... a popravdě, mrknul jsem na wiki, a ani já nevím, jak to sídlo firmy
> správně otagovat, žádný jiný shop= to nepokrývá, office= mi tam taky nic
> nesedí ...?
> 
> K.

ok, stačilo si postěžovat :-)

http://wiki.openstreetmap.org/wiki/Tag:craft=insulation

K.


signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk] Forum admin(s) wanted

[Daniel Koć]

W dniu 15.07.2016 0:42, Michał Brzozowski napisał(a):

Somebody also tried to contact Lambertus to no avail, asking for
creation of users:Iceland
http://forum.openstreetmap.org/viewtopic.php?id=55089


It's not created yet, however (as a forum moderator) I've just found 
that last action on report he took on 2016-07-11 21:57:05, so he's not 
entirely absent. He's just hard to contact, we don't know what's going 
on and who could act instead of him, which is still bad enough for me.


--
"Low, low, low..." [M. Kempa]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] MAppiaM! Mappatura monumenti Appia Antica 9-11 luglio 2016

[Aury88]

dieterdreist wrote
> nella pratica non viene quasi mai fatto, perché chi usa dei tags più
> dettagliati mette archaeological site ;-)
> Ruins potrebbe essere anche una cosa di recente costruzione oppure
> addirittura mai compiuta.
> 
> Rimane il fatto che c'è del "overlap" tra ruins e archaeological site e
> spetta al mappatore decidere cosa mettere.


io fino ad oggi ho sempre preferito estendere archaeological_site all'area
del sito archeologico che, comprendendo così di solito più tipologie di
elementi, non usavo per indicare i singoli tipi di reperto/monumento ma
semplicemente la tipologia generica (se possibile), il periodo e la civiltà
dei reperti all'interno del sito. non ho mai messo un archaeological_site
dentro un altro onestamente ritenendo il tag ruins=tipo_di_elemento
sufficiente per la descrizione appunto dei vari elementi all'interno del
sito...

mi spiace, ma come stile il mettere un archaeological_site dentro l'altro
non mi convince perchè  si userebbe lo stesso tag sia per indicare i
reperti, sia per indicare il "confine" di un area archeologica che contiene
anche cose che non sono reperti (cestini, panchine, strade, servizi,
biglietteria, lampioni), almeno nel mio caso per come utilizzo
solitamente il tag archaeological_site uscirebbe una cosa del genere.

effettivamente il mio stile potrebbe non andare bene per indicare altri tipi
di elementi che non siano rovine, ma secondo me con il Lifecycle prefix si
potrebbe riuscire a sopperire alle mancanze del mio metodo...

decidiamo per bene come fare e appena potrò mi metto a modificare il wiki in
base a cosa viene deciso :-)



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/MAppiaM-Mappatura-monumenti-Appia-Antica-9-11-luglio-2016-tp5876562p5878531.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Fwd: Re: edity z maps.me

[Karel Volný]

zdar,

> Obavam se, ze to bude cim dal horsi, prave koukam ze tam je cim dal vic
> pokusu o zverejnovani jakesy reklamy. Zacinam mit dojem, ze nejlepsi
> reseni by bylo bot, ktery to bude vse rovnou mazat.
> 
> http://www.openstreetmap.org/note/629304
> 
> A naprosto nejhorsi na tom je prave to, ze to nacpou i rovnou do mapy.

tož zase toto konkrétně ale až tak špatně nedopadlo, až na ten shop=outdoor

... a popravdě, mrknul jsem na wiki, a ani já nevím, jak to sídlo firmy 
správně otagovat, žádný jiný shop= to nepokrývá, office= mi tam taky nic 
nesedí ...?

K.


signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk] KG ground survey

[Milo van der Linden]

I found out they are "Kaart group" http://www.kaartgroup.com/ and will
contact them.



2016-07-16 11:52 GMT+02:00 Milo van der Linden :

> Hello,
>
> I am involved with community mapping activities in the Caribbean, on
> Aruba, Curacao and Jamaica.
>
> We often come across "KG Ground Survey" tags and a little investigation
> tells me their area of operation is the Caribbean as well (see attached
> image).
>
> I would like to get in touch. Is there anybody here that is part of the KG
> team that wants to discuss collaboration?
>
> Kind regards,
>
> Milo
>



-- 
[image: http://www.dogodigi.net] 
*Milo van der Linden*
web: dogodigi 
tel: +31-6-16598808
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-ht] Recrutement d'enqueteurs et autre qualificatifs

[Louino Robillard]

Ann kontinye fe konbit.

*Konbit pa vle di pou w pa travay pou entere pwop tet paw, men konbit la
vle di mete ak lot moun, ansanm pou travay pou entere nou.

Se nan konbit fos nou chache.
Yon sel dwet pa manje kalalou.
1=1
Men 1+1=2

Ann kontinye fe konbit
Robi.
On Jul 15, 2016 3:27 PM, "ALCE, Samuel Paul" 
wrote:

Lots of respect Jean Bully Prophete... One of the good ones!
Mwen sur ke Bully se youn nan bon yo
NAP BATAY POU KONBIT LA FET E NAP KONTINYE FE KONBIT NOU PAP LACHE
MENM SI YO PANSE NAP BATAY POU ENTERE PA NOU...
Robi mwen salye sou track sa...

KONBIT PI RED





Le 15 juillet 2016 à 16:18, Jean Bully PROPHETE  a
écrit :

> Veuillez aller sur ce lien et appliquez pour votre qualificatif:
> offre d'emploi 
> A tous les membres de COSMHANNE c'est un des points que je voulais vous
> parler alors tentez votre chance, ceci pourrait etre beaucoup plus formel
> cependant je ne voulais pas continuer a violer votre charte.
>
> Merci
>
> --
> * Jean Bully Prophete*
> GIS Field Agent at DAI/AVANSE Haiti
> Humanitarian OpenstreetMap Team member / OSM Advanced Mapper-Trainer
> 
> Skype:jeanbully
> Linkedin: Jean Bully
> <
>
https://www.linkedin.com/profile/view?id=AAIAAAsyuO8B57pdiqGkMfBwnWlmW99xXTaOhVU=nav_responsive_tab_profile_pic
> >
> Phone/Whatsapp:+1(509)3732-2379
> ___
> Talk-ht mailing list
> Talk-ht@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ht
> Notez! Vous pouvez utiliser Google Translate (http://translate.google.com)
> pour traduire les messages.




--
*ALCE Samuel Paul, *

*Port-au-Prince, Haiti *

*Field Data Coordinator @ DAI / USAID*
*Géo-Information Specialist (GIS)*

*Humanitarian OpenStreetMap Team memberOpenStreetMap** contributor in
Haiti *

*OSM username: ALCE Samuel Paul *

*Cell**: (509) 4894-2175 / 4638-4875 / 4289-7651

 *
*Skype**: samuelalce*
*Whatsapp*: *(509) **4289-7651*
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com)
pour traduire les messages.
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.

Re: [Talk-it] MAppiaM! Mappatura monumenti Appia Antica 9-11 luglio 2016

[Martin Koppenhoefer]

sent from a phone

> Il giorno 16 lug 2016, alle ore 09:24, Aury88  ha 
> scritto:
> 
> concordo sul reperto un po meno sul ruins...teoricamente ruins oltre che yes
> accetta value che descrivono cosa erano prima di diventare rovine.


nella pratica non viene quasi mai fatto, perché chi usa dei tags più 
dettagliati mette archaeological site ;-)
Ruins potrebbe essere anche una cosa di recente costruzione oppure addirittura 
mai compiuta.

Rimane il fatto che c'è del "overlap" tra ruins e archaeological site e spetta 
al mappatore decidere cosa mettere.

Ciao,
Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] PID na transit.land

[Petr Holub]

> objevil jsem, že někdo nahrál data jízdních řádů PIDu na transit.land.
> 
> To znamená, že je možné je používat ve routovací službě Mapzen Turn-by-turn.
> 
> Viz demo - http://valhalla.github.io/demos/routing/multimodal.html
> 
> To uživatelské rozhraní je dost tristní, ale je to pokrok co se týká 
> otevírání dat jízdních
> řádů.

Mozna lepsi demo je tady:

https://mapzen.com/products/turn-by-turn/?d=0=40.7259=-73.9805=12=multimodal_lat=37.737089_lng=-122.504467=SF%20Zoo_lat=37.80927_lng=-122.25981=699%20Bellevue%20Avenue%2C%20Oakland%2C%20CA%2C%20USA_bus=0.5_rail=0.6_transfers=0.4=2016-07-19T08%3A00_type=1

Petr


___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

[talk-ph] Fwd: [OSM-talk] weeklyOSM #312 05.07.2016-11.07.2016

[Eugene Alvin Villar]

-- Forwarded message --
From: weeklyteam 
Date: Fri, Jul 15, 2016 at 8:09 PM
Subject: [OSM-talk] weeklyOSM #312 05.07.2016-11.07.2016
To: t...@openstreetmap.org


The weekly round-up of OSM news, issue # 312,
is now available online in English, giving as always a summary of all
things happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/7855/

Enjoy!

weeklyOSM is brought to you by ...
https://wiki.openstreetmap.org/wiki/WeeklyOSM#Languages
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [Talk-it] MAppiaM! Mappatura monumenti Appia Antica 9-11 luglio 2016

[Aury88]

Andrea Lattmann wrote
> Scusate, ma forse, per le mie scarse conoscenze linguistiche non riesco a
> capire dove sia sbagliata la frase. Forse la interpreto male. 
> Non è che intendano dire che non solo i siti "scavati" intesi anche le
> zone ancora da scavare sono da considerarsi siti archeologici, ma anche
> quelli che sono visibili senza intervento umano, ad esempio le incisioni
> rupestri?? 

si, in effetti la tua interpretazione sembra quella giusta...si vede che da
oggi dovrò limitarmi a mappare elementi con il wiki in italiano xD



-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/MAppiaM-Mappatura-monumenti-Appia-Antica-9-11-luglio-2016-tp5876562p5878526.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] MAppiaM! Mappatura monumenti Appia Antica 9-11 luglio 2016

[Aury88]

Andrea Lattmann wrote
>>per me il reperto è una cosa più piccola, >una vasa, una statua, ecc.
> 
> Non vorrei dire una sciocchezza, ma anche una costruzione è un reperto, mi
> viene in mente la casa retica delle botti e delle ruote a Bressanone. Ora
> recupero un documento che fa luce sul significato di reperto. Concordo sul
> discorso del ruins.

concordo sul reperto un po meno sul ruins...teoricamente ruins oltre che yes
accetta value che descrivono cosa erano prima di diventare rovine...queste
rovine poste dentro un sito archeologico (che dovrebbe avere associati i 
tag sul periodo storico e la cultura del sito) imho danno un idea quanto
meno generale della natura dell'oggetto e comunque secondo me interpretabile 




-
Ciao,
Aury
--
View this message in context: 
http://gis.19327.n5.nabble.com/MAppiaM-Mappatura-monumenti-Appia-Antica-9-11-luglio-2016-tp5876562p5878525.html
Sent from the Italy General mailing list archive at Nabble.com.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Fwd: Re: edity z maps.me

[jzvc]

Dne 14.7.2016 v 16:26 Jan Martinec napsal(a):

Tak to vypadá, že situace minimálně není až tak hrozivá - něco dat k
náhodnému vzorku. TL;DR: Díky maps.me  více uživatelů a
dat, z toho tu a tam někdo kraví.


Obavam se, ze to bude cim dal horsi, prave koukam ze tam je cim dal vic 
pokusu o zverejnovani jakesy reklamy. Zacinam mit dojem, ze nejlepsi 
reseni by bylo bot, ktery to bude vse rovnou mazat.


http://www.openstreetmap.org/note/629304

A naprosto nejhorsi na tom je prave to, ze to nacpou i rovnou do mapy.

http://www.openstreetmap.org/note/629304
http://www.openstreetmap.org/note/629304

atd atd



http://www.openstreetmap.org/user/manoharuss/diary/39050


HPM

(Mimochodem, linkuje tam dva nové nástroje pro QA)


Dne 11. 7. 2016 8:22 dop. napsal uživatel "Milan Cerny"
>:

Včera jsem si trochu hrál s Maps.me a zkusil i něco přidat.
Trochu mě překvapilo, že aplikace umožní přidat i to, co sama
nedokáže zobrazit, což nahrává k tvorbě duplicit.
Problém je v nastavení mapy. Pokud je nastaven 3D pohled, některé
body se nezobrazí, v 2D je vidět vše.
V režimu editace, tedy upřesnění polohy nového POI, se mapa přepne
do 2D a skryté objekty se zobrazí, takže jistý nástroj proti tvorbě
duplicit tu je.
Toho si ale uživatel nemusí všimnout. Například telefon, nebo koš se
zobrazí šedě na šedém podkladu, což lze snadno přehlédnout.
Ještě to bude chtít dotáhnout.

Milan

__ Původní zpráva: 
 > Od: Jan Martinec >
 > Komu: OpenStreetMap Czech Republic >
 > Datum: 08.07.2016 15:55
 > Předmět: Re: [Talk-cz] edity z maps.me 
 >
To je to nejmenší - name:zh by db schroupala a ještě by se oblízla.
Problém
je v povaze dat: "tady v hostelu bydlím" se zdá být častý zdroj
duplicit.
Navíc to vypadá, že @Zverik si bere veškerou kritiku velmi osobně, a tím
vylévá dítě i s vaničkou - viz followup tady:
http://www.openstreetmap.org/user/BushmanK/diary/38946
byť uznávám, že jít proti maps.me  s tezí "je to
zlo,zlo,zlo" taky nepomáhá.

Nicméně se nejspíš rýsuje aspoň kontrola duplicit poblíž; jak rychle
se to
objeví u  uživatelů, to je jiná věc (a jestli to bude kontrolovat i
bus_stop vs bus_station, jako ten dnešní na Florenci).

HPM
Dne 8. 7. 2016 3:20 odp. napsal uživatel "Miroslav Suchy"

 >:

 > Dne 8.7.2016 v 14:35 Jan Martinec napsal(a):
 > > Číňanům v Praze je to fuk a mydlej to tam hlava nehlava.
 >
 > Jj. Hlavně píšou poznámky v čínštině, což je velká legrace :)
 >
 > Mirek
 >
 > ___
 > Talk-cz mailing list
 > Talk-cz@openstreetmap.org 
 > https://lists.openstreetmap.org/listinfo/talk-cz
 >


--

___
Talk-cz mailing list
Talk-cz@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-cz

___
Talk-cz mailing list
Talk-cz@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-cz



___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz




___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk] highway=crossing tags removed in changeset.

[Greg Morgan]

On Wed, Jul 13, 2016 at 11:04 AM, Alejandro S.  wrote:
> Hi,
> Looks like somebody making automated edits without checking by survey what
> they are doing...
>
> I think it should be reverted.
>
> Kind regards,
>   Alejandro Suárez

Alejandro,

Did you even read the change history of any nodes such as node
http://www.openstreetmap.org/node/729984457/history or consult the
tagging page on the subject before you making the allegation that this
was an automated edit?
"crossing=no Where definitely no crossing is possible/legal. This tag
must be used without a highway=crossing, so data consumers only
evaluating the high-level highway tag are not mislead into assuming a
crossing here.
As crossing=no excludes the existence of a crossing, the combination
of highway=crossing and crossing=no is invalid.
Thus, if there is a place where one would expect a crossing but where
is definitely no crossing, you may tag this with crossing=no but
without highway=crossing.

It is obvious from the history and experience with Josm's noisy
validator that his is not an automated edit.   Wynndale was merely map
gardening.  The obvious change for this node is highway=crossing and
crossing=unmarked.  I say that because of the two lane looking cycle
way that crosses the road.  crossing=no may have been UniEagle's
attempt at crossing=unmarked.
1.) Edit 1 5/11/2010 NaN135709 adds the node at the crossing.
2.) Edits 2 to 5 from 6/29/2011 to 4/22/2014 all have the missing
crossing information.
3.) Finally on edit 6 on 4/22/14 roughly four hours after edit 5
UniEagle adds highway=crossing and crossing=no.  And when we look at
the wiki diff history, we can defend UniEagle's decision because there
wasn't much information at the time.
http://wiki.openstreetmap.org/w/index.php?title=Key%3Acrossing=revision=1012147=963951
4.) Edit 7, the edit under dispute, Wynndale removes the
highway=crossing tag following the first sentence of the wiki page and
the rest of the paragraph.

The better option follows on the next sentence of wiki:
"crossing=unmarked A crossing without road markings or traffic lights"

So how about coaching the mapper verses reverting the changeset or
making an allegation. Even the original tagging is wrong.  Why would
you want to revert a change that is right based on the wiki to
something that is wrong to begin with?  How about clarifying the wiki
page before accusing someone of an automated edit?  How about let's
congratulate Wynndale on a brave attempt at map gardening in such a
hostile environment?

Regards,
Greg

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk