Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

2020-05-25 Per discussione Philippe Verdy
Ce code source n'apporte strictement rien.

Pas même sa description qui est fonctionnellement aberrante concernant la
formule des "node id", un pseudo-hashcode qui n'en est même pas un, qui
réclame un nombre premier pour encoder le couple de coordonnées alors que
cela n'a rien à voir et qu'il n'est pas nécessaire du tout que ce soit
premier, on peut directement utiliser "180*10^precision" à la place de
"prime" en voyant que les latitudes sont données en degrés entre -90.0
et +90.0, ou bien  "360*10^precision" si les latitudes ne sont pas
normalisées à cet intervalle et reboucle chaque méridien avec son
antiméridien (au quel cas un module 360 suffit sur chacune des deux
coordonnées à les normaliser "à moitié", sans unifier un point et son
antipode situé à la même longitude mais à la latitude+180°)

   round(mod(lat, 360), precision) + round(mod(lon, 360) , precision) *
360*10^precision

Les arrondis sont mal exprimés aussi dans la formule originale qui va donc
confondre une partie de la précision de la longitude en recouvrant des
points ailleurs à une autre longitude.

[Pour une unification complète des points antipodiques, il faut un test
d'intervalle pour la latitude modulo 360, pour la ramener à un intervalle
large de 180°, en ajoutant ou pas 180° à la longitude, selon la parité de
l'intervalle de latitude, et en remplaçant ou pas la latitude par son
complémentaire à 180° selon la même parité]. Et je pense même que c'est
inutile à moins que la base QGis stocke des coordonnées non normalisées
(avec des latitudes hors de -90.0 à +90.0, même s'il est probable qu'elle
puisse avoir en revanche des longitudes hors de l'intervalle -180.0 à +180°
pour la cartographie le long de la ligne de changement de date (aux îles
Kiribati, aux île Kouryles et à travers la pointe du Kamtchatka en Sibérie
extrême-orientale, et sinon sur le continent antarctique dans le secteur
revendiqué par l'Australie).

Et concernant le paramètres "layer" qui multiplie le tout, c'est encore
plus stupide, sa seule valeur valide est 1, toute autre valeur n'apporte
rien d'autre qu'un changement d'échelle des ids, sauf la valeur 0 qui rend
tous les ids générés nuls.

J'espère qu'une telle formule (totalement fausse) n'a jamais réellement été
utilisée pour importer des géométries dans OSM!



> Le mer. 13 mai 2020 à 16:25,  a écrit :
>>
>>> DCbrain rend public un convertisseur de données, sur son compte Github.
>>> Il s'agit d'un convertisseur de données géographiques postgresql en format
>>> openstreetmap
>>> Apparemment c est en rapport avec OSRM
>>> Source:
>>> https://www.programmez.com/actualites/dcbrain-rend-publique-une-partie-de-son-code-en-open-source-30553
>>
>>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

2020-05-25 Per discussione Philippe Verdy
Est-ce que ce n'est pas fonctionnellement équivalent au greffon pour JOSM
de chargement de données depuis une base QGis (donc sans la génération de
fichier XML .osm, que JOSM fait lui-même, juste la partie requête SQL)?

Le mer. 13 mai 2020 à 17:35, François Lacombe  a
écrit :

> Salut,
>
> Merci pour le relais.
> J'ai eu l'occasion de tremper dans cette sombre affaire.
>
> Le convertisseur est utilisé pour alimenter OSRM, mais c'est surtout le
> réciproque de osm2pgsql.
> Il produit un fichier xml osm à partir d'une base postgis.
>
> Cela ayant pour avantage de bénéficier de la force de postgis et de
> données tierces pour utiliser des logiciels qui n'acceptent que du xml en
> entrée.
> La valeur ajoutée résident dans le code SQL de création de la topologie
> avec les bonnes connections plus que dans l'écriture du XML qui devrait
> être revue prochainement.
>
> A dispo pour plus d'explications
>
> François
>
> Le mer. 13 mai 2020 à 16:25,  a écrit :
>
>> DCbrain rend public un convertisseur de données, sur son compte Github.
>> Il s'agit d'un convertisseur de données géographiques postgresql en format
>> openstreetmap
>> Apparemment c est en rapport avec OSRM
>>
>> Source:
>> https://www.programmez.com/actualites/dcbrain-rend-publique-une-partie-de-son-code-en-open-source-30553
>>
>> Julien
>>
>> ___
>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[OSM-ja] 災害救援自動販売機について

2020-05-25 Per discussione たか
今月から参加させていただきますtak-yと申します。現地踏査の際に、自動販売機のなかでも災害による停電が起きた時に遠隔操作やキーなどによって飲料が提供される「災害救援自動販売機」を見つけたのですが、vendorとemergencyのタグを探しても当てはまりそうなものが見当たらず、苦慮しています。どのようなタグ付けが好ましいのでしょうか。よろしくお願いいたします。 Windows 10 版のメールから送信 ___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja


Re: [OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Per discussione Philippe Verdy
la confusion entre T et ter ne semble pas exister, pas plus que Q et
quater. Elle ne concerne que B et bis. Mais qu'on mette "bis" ou "BIS" dans
la base, avec ou sans espace, ce n'est pas ambigu. L'ambiguité ne concerne
que le B: il faut bien indiquer avant tout qu'on ne doit pas abréger "bis",
et que "B" ou "b" c'est la même chose (avec ou sans espace) et jamais un
"bis". La normalisation ensuite (capitales ou pas, espace ou pas) c'est
très secondaire, les usages varient selon les sources (Cadastre, annuaires,
publicité/annonces).

On limite les cas d'erreurs aux seules occurences de B qui ont été abrégées
là où il ne fallait pas (mais où aucune correction automatique ne peut
avoir lieu pour changer l'un de "b" ou "bis" en l'autre, même si la
normalisation a lieu (elle n'a pas beaucoup d'intérêt à être faire dans la
base, ça peut se faire côté client, y compris au sein de Nominatim qui peut
traiter comme synonymes les différences de capitales ou l'absence/la
présence d'une espace entre le numéro et un bis/ter ou une lettre seule).

Et je ne vois pas où on aurait un "à" après un numéro pour indiquer un nom
de rue, ce "à" devrait être absent, donc le "A" ou "a" seul est un indice
(sinon il faut mettre l'accent et l'espace avant, et là on doit corriger
les erreurs dans la base).

Bref ne sont à vérifier (manuellement) que les "a" après l'espace et les
"b" avec ou sans l'espace avant, sans tenir compte des différences de casse
(le "a" seul peut être normalisé en capitale mais on ne sait pas s'il
devrait être collé au numéro ou détaché en mettant l'accent oublié, donc
aucun intérêt à automatiser cette normalisation de même qu'il est
inutile d'automatiser la capitalisation des b, la normalisation peut être
automatisée en revanche pour les "bis/ter/quater",  et les autres lettres
seules à partir de C, en faisant attention toutefois au D ou L suivi de
l'apostrophe, parfois omise ou remplacée par une espace dans les fichiers
postaux puisque la Poste préconise encore aucune apostrophe ni autre
ponctuation, pas même le trait d'union!).


Le lun. 25 mai 2020 à 23:19, Jérôme Seigneuret 
a écrit :

> Comme dit @marc on peut simplement spécifier le mode d'écriture sans
> espace et majuscule pour les lettres (bâtiment entrée ) et minuscules pour
> bis ter quater etc dans les bonnes pratiques.
>
> Le lun. 25 mai 2020 à 19:01, Yves P.  a écrit :
>
>> > il n'y a pas besoin de tableau pour lister 3-4 abréciations, parler de
>> > l'espace et de capitale<>minuscule, au contraire les tableaux de 26
>> > lignes pourêtre ultra complet, sont hyper lourd parce qu'on passe
>> > son temps à les lire croyant qu'il y a une info particulière
>> > autre que le déluge
>>
>> Pas sur d'avoir tout saisi. Je parlais du tableau dans la page wiki addr,
>> pas d'un nouveau tableau listant tout les cas :)
>>
>> __
>> Yves
>> ___
>> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Per discussione Jérôme Seigneuret
Comme dit @marc on peut simplement spécifier le mode d'écriture sans espace
et majuscule pour les lettres (bâtiment entrée ) et minuscules pour bis ter
quater etc dans les bonnes pratiques.

Le lun. 25 mai 2020 à 19:01, Yves P.  a écrit :

> > il n'y a pas besoin de tableau pour lister 3-4 abréciations, parler de
> > l'espace et de capitale<>minuscule, au contraire les tableaux de 26
> > lignes pourêtre ultra complet, sont hyper lourd parce qu'on passe
> > son temps à les lire croyant qu'il y a une info particulière
> > autre que le déluge
>
> Pas sur d'avoir tout saisi. Je parlais du tableau dans la page wiki addr,
> pas d'un nouveau tableau listant tout les cas :)
>
> __
> Yves
> ___
> 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-de] Position des FOSSGIS e.V. zu bezahlten Kräften in der OSMF

2020-05-25 Per discussione Florian Lohoff

Hola,

On Mon, May 25, 2020 at 10:14:23PM +0200, Michael Reichert wrote:
> 
> Eine gemeinsame Position des FOSSGIS e.V. als Local Chapter der OSMF in
> Deutschland zu diesem Thema wird Tagesordnungspunkt auf der nächsten
> Vorstandsitzung des FOSSGIS e.V. am Dienstag, den 1. Juni 2020 um 20:00
> Uhr auf dem Mumble-Server podcast.openstreetmap.de sein.
> 
> Welche Meinung habt ihr zu bezahlten Kräften in der OSMF dazu? Stimmt
> ihr dem obigen Konsens zu? Oder seid ihr anderer Meinung?

Ich habe die original Mail gesehen und hab da nen ganzen Tag so
"drauf rum gekaut" und irgendwie fällt es mir schwer eine Tätigkeit
zu definieren die nicht dem ein oder anderen auf die Füße tritt.

Ich sehe halt den Sysadmin Kram für die OSM Server als eine Baustelle.
Das wird irgendwann zu einem Fulltime job den nicht mal irgendwer
nebenher macht. Aber wie will man Freiwillige da mit reinziehen.
Das ist so ein "ganz oder gar nicht" Nummer. Also Entweder zahlst
du dann das ganze Admin Team oder keinen - Aber so einen raus picken
der dann Full time dabei ist und noch eine Herde von Zuarbeitern? Ich
kann mir nicht vorstellen das so etwas funktioniert. Dann lieber allen
einen Halbtagsjob anbieten. Oder sowas wie Nachteinsätze, Bereitschaft
oder so zahlen.

Aber vielleicht denke ich zu kurz was die OSMF Tätigkeiten angeht. Mit
der europäischen Brille ist ja die OSMF eine technische
Erfüllungsgehilfin. Das wird in den USA ja anders wahrgenommen. Da ist
das ja eher ein "Political body" und da geht es dann vermutlich viel
mehr um Community, Lobbying und Co.

Und ja - ich fände es auch gut wenn es einen breiten Konsens geben würde
welche Tätigkeiten da bezahlt werden und das es quasi abgestimmte
Tätigkeitsbeschreibungen gibt. Daher finde ich den Kompromiss gut.

Ich habe ja überhaupt keine Links zu der Wikimedia - Aber die haben ja
auch irgendwann angefangen Menschen zu bezahlen und haben da den ein
oder anderen Fehler begangen. Vielleicht kann man da draus lernen?

Und wenn ich die Liste heute durchgucke dann Frage ich mich was die alle
machen?! Gefühlt gibt es da für jedes byte einen Senior FooBar.

https://wikimediafoundation.org/role/staff-contractors/

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Talk-it] Separazione strade

2020-05-25 Per discussione Manuel
Anche io preferisco di gran lunga usare i tag turn:lanes, ma in questo caso ero 
in dubbio proprio a causa dell'isola zebrata dipinta.

⁣Manuel Tassi

Il giorno 25 mag 2020, 21:58, alle ore 21:58, Lorenzo Mastrogiacomi 
 ha scritto:
>Il giorno lun, 25/05/2020 alle 20.24 +0200, Damjan Gerl ha scritto:
>> Manuel je 25.5.2020 ob 14:51 napisal:
>>
>>
>>
>> >
>> >   Sulla Wiki ho notato che esistono due diverse convenzioni
>> > per quanto riguarda la separazione delle ways: una prende
>> > in
>> > considerazione le divisioni fisiche (barriere, isole di
>> > traffico, ecc.), mentre l'altra prende in considerazioni
>> > anche
>> > separazioni de facto (come per esempio una linea doppia
>> > continua prima di una separazione). Sulla
>> >   Wiki viene indicato che potrebbero esserci delle
>> > convenzioni specifiche, ma non ho trovato niente per quanto
>> > riguarda una convenzione italiana. Quindi volevo chiedere:
>> > potremmo decidere come comportarci unitariamente per questo
>> > tipo
>> > di convenzioni?
>> >
>> >
>> >
>> > Il dubbio è nato dopo una domanda arrivata nel gruppo
>> > Telegram:
>> > vicino Portogruaro, precisamente in località Mazzolada, c'è
>> > un'intersezione che al momento è stata creata usando
>> > diversi
>> > tipi di way (allegato 1). La divisione a monte della strada
>> > è
>> > stata fatta perché, prima dell'intersezione, è presente una
>> > separazione delle due linee tramite isola zebrata (non
>> > fisica,
>> > quindi, ma solo dipinta; allegati 2 e 3) e, più avanti, nel
>> > punto specifico dell'intersezione, è stata creata una
>> > ragnatela
>> > di way a senso unico (allegato 1). Da
>> > qui è nata la ricerca perché: se lasciamo come ora niente
>> > da
>> > cambiare, ma ci teniamo una ragnatela di way; se la
>> > separazione
>> > tramite isola dipinta non la vogliamo considerare come una
>> > separazione della strada e la strada si può mappare usando
>> > una
>> > sola way, bisogna ricorrere ai tag lanes.
>> >
>> >
>>
>> 
>>
>> Questa io la vedrei molto meglio con una sola way, quindi non
>> separata. Così è un po' incasinata. Per quello che ne sapevo si
>> disegna la way separata solo se fisicamente separata, tranne che
>> per
>> qualche rara eccezione.
>>
>>
>>
>> Damjan
>>
>>
>>
>>
>
>Anche per me è una complicazione inutile.
>Anzi, volendo mappare le corsie di svolta, credo che si ottengano
>risultati anche migliori utilizzando turn:lanes=* su una way singola.
>
>
>Lorenzo
>
>
>
>
>___
>Talk-it mailing list
>Talk-it@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-it
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-de] Massenweise Entfernung von oneway=no

2020-05-25 Per discussione Rainer via Talk-de

Oh, lit ist gut. Als mir das erste Mal ein Waldweg mit lit=no begegnete,
habe ich das gelöscht, weil ich dachte, da hat jemand zu brav alle Werte
der Vorlage im Editor ausgefüllt. Später, als mir das noch einige Male
begegnete habe ich's gelassen, denn es ist ja nicht falsch, aber halt
total unnötig.

Im Grunde haben wir das Problem, daß ein fehlendes Tag default bedeutet,
aber nicht von einem gesetzten mit default-Wert unterscheidbar ist. Das
könnte man zwar lösen, indem ein Editor den Wert "unknown" setzt, wenn
der Benutzer nicht "yes" oder "no" auswählt. Es würde aber dazu führen,
daß jedes Objekt Unmengen an Tags Schlüssel=unknown bekommt, alles was
so denkbar ist für ein solches Objekt. Also alles das, was Tobias als
"zu Lasten der Übersichtlichkeit" beschrieben hat.
Was als default angenommen wird, kann und sollte im Wiki festgelegt
sein. Es kann aber durchaus für Wegtypen oder allgemein Objektarten
unterschiedliche default-Werte geben und sie können regional abweichen.
Wer in Belgien aufgewachsen ist, könnte bei der ersten Auslandsreise
versucht sein an Autobahnen lit=no zu ergänzen bis er merkt, daß "no"
nicht die Ausnahme ist. Aber ein Fußweg ist bei lit=yes|no anders zu
behandeln als eine Autobahn. Da würde ich es nicht wagen fehlendem lit=*
einen Defaultwert zuzuordnen.
Insofern, ja genau, der gesunde Menschenverstand sollte ein gutes
Hilfsmittel sein bei der Überlegung, ob ein Schlüssel mit einem
Defaultwert gesetzt wird oder eben nicht, weil es eh klar ist. Ich
investiere meine Zeit für OSM lieber, um Dinge zu erfassen, die wirklich
noch fehlen oder sich geändert haben, als großflächig Defaultwerte
hinzuzufügen. Aber Löschen in der Regel auch nicht.

- Rainer


Am 25.05.20 um 20:44 schrieb Florian Lohoff:

On Mon, May 25, 2020 at 01:08:33AM +0200, Tobias Knerr wrote:

Meiner Meinung nach geht die Idee, Default-Werte explizit zu setzen, zu
Lasten der Übersichtlichkeit. Die logische Konsequenz wären ja
maxweight=none, maxheight=none, bridge=no, tunnel=no, covered=no
access=yes vehicle=yes motor_vehicle=yes etc. an fast jeder Straße. Und
wie mappe ich z.B., dass zwischen zwei Straßen keine Abbiegebeschränkung
besteht – lege ich dann jeweils eine Relation mit restriction=allowed
an? Wie mappe ich, dass an einer Stelle kein Gebäude steht, in einem
Gebäude kein weiterer Laden mehr ist, auf dem Gehsteig kein weiterer
Abfalleimer steht, ...?

Vielleicht etwas übertrieben, aber worauf ich hinaus will: Die
Abwesenheit von einem Objekt oder Attribut sollte normalerweise nicht
erfasst werden – nur in Ausnahmefällen dort, wo sie überraschend ist
(weil es kürzlich anders war, die Luftbilder veraltet sind, es bei den
Straßen drumherum anders ist, ...) . Wenn in deiner Gegend bestimmte
Arten von Straßen oft "umgedreht" werden, kann das durchaus so ein Fall
sein.

Ich überlege gerade was ist mit lit/cycleway/sidewalk/shoulder ?

So einfach ist es eben nicht. Es gibt zwar defaults die auch Sinn
machen. Es gibt dinge deren "seltenheit" macht es Unsinning eben
den umgekehrten fall zu taggen oneway=no als Beispiel.

Aber was ist mit lit? Da sind ja sowohl lit=no wit auch lit=yes eine
information. Und bei lit ist die Verteilung eher 80/20.

Was ist mit sidewalk=no, cycleway=no? hat ja ggfs im Routing
eine Auswirkung je nach Straßenklasse. Auf einem residential mit
sidewalk=no will ich vielleicht noch laufen. Auf einem primary mit
lit=no, sidewalk=no vermutlich eher nicht - vor allem nicht Nachts.

Also die Regel das nur weil etwas NICHT existiert wir es nicht taggen
ist zu kurz gesprungen.

Ich glaube das funktioniert im Moment nur deshalb weil jeder da seinen
Menschenverstand benutzt - oder eben auch nicht.

Ich denke man müsste für jedes tag einzeln durchgehen ob es Sinn macht
yes UND no zu taggen und wenn ja wann.

Und für einiges haben wir defaults, für anderes aber eher so nicht - bzw
eher undokumentiert und gefühlt.

Flo

___
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


[Talk-de] Position des FOSSGIS e.V. zu bezahlten Kräften in der OSMF

2020-05-25 Per discussione Michael Reichert
Hallo,

auf der Mailingliste OSMF-Talk gab es, angestoßen vom OSMF-Vorstand, vor
etwa zwei Wochen eine Diskussion über bezahlte Kräfte in der OSM
Foundation [1]. Wir haben heute Abend auf dem FOSSGIS-OSMF-Stammtisch
lange über bezahlte Kräfte in der OSMF diskutiert.

Konsens der Diskussion war:

- Für die Vergabe von Tätigkeiten an bezahlte Kräfte, sollte der
  Vorstand vorher eine Tätigkeitsbeschreibung aufstellen und
  sicherstellen, dass die Tätigkeit in die Zuständigkeit der OSMF fällt
  und kein Engagement Freiwilliger verdrängt wird.
- Die Mitglieder sollten den Grundsätzen der Personalpolitik zustimmen.
  Sie sollte der Schaffung neuer Stellen auf Basis der
  Tätigkeitsbeschreibung zustimmen.
- Die OSMF soll als Arbeitgeber/Auftraggeber ihrer sozialen
  Verantwortung gegenüber den für sie Tätigen gerecht werden.

Eine gemeinsame Position des FOSSGIS e.V. als Local Chapter der OSMF in
Deutschland zu diesem Thema wird Tagesordnungspunkt auf der nächsten
Vorstandsitzung des FOSSGIS e.V. am Dienstag, den 1. Juni 2020 um 20:00
Uhr auf dem Mumble-Server podcast.openstreetmap.de sein.

Welche Meinung habt ihr zu bezahlten Kräften in der OSMF dazu? Stimmt
ihr dem obigen Konsens zu? Oder seid ihr anderer Meinung?

Viele Grüße

Michael



[1] https://lists.openstreetmap.org/pipermail/osmf-talk/2020-May/006816.html



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


Re: [OSM-talk] Should we map things that do not exist?

2020-05-25 Per discussione 80hnhtv4agou--- via talk

i would delete what i did, expanding on someone else edit,  but what about 
something like a road 
 
that was never built and was mapped 7 years ago, with an edit 1 year ago ?
  
>Sunday, May 24, 2020 11:39 PM -05:00 from Jack Armstrong 
>:
> 
>Greetings.
> 
>Recently, a user mapped “razed” railways inside a construction zone (link 
>below). These rails had been removed by our local mappers since they don’t 
>exist anymore. Using the latest imagery (Maxar), you can see the rails have 
>been completely removed from “Project 70”, a $1.2 billion Denver-area 
>transportation corridor construction project.
> 
>I think this mapper has good intentions, but what is the point of mapping 
>something that does not exist? Doesn’t this clearly contradict the OSM Good 
>Practice wiki in regards the sections, “Verifiability”, “Map what's on the 
>ground” and “Don't map historic events and historic features”? The last 
>section states, " Do not map objects if they do not exist currently ."
> 
>Should we tag (invisible) razed sidewalks? Should we leave (invisible) 
>destroyed buildings in place, tag them as razed and then create new buildings 
>on top of them?
> 
>https://www.openstreetmap.org/edit#map=19/39.78016/-104.94562
> 
> 
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk 
 
 
 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-it] Separazione strade

2020-05-25 Per discussione Lorenzo Mastrogiacomi
Il giorno lun, 25/05/2020 alle 20.24 +0200, Damjan Gerl ha scritto:
> Manuel je 25.5.2020 ob 14:51 napisal:
> 
> 
> 
> >   
> >   Sulla Wiki ho notato che esistono due diverse convenzioni
> > per quanto riguarda la separazione delle ways: una prende
> > in
> > considerazione le divisioni fisiche (barriere, isole di
> > traffico, ecc.), mentre l'altra prende in considerazioni
> > anche
> > separazioni de facto (come per esempio una linea doppia
> > continua prima di una separazione). Sulla
> >   Wiki viene indicato che potrebbero esserci delle
> > convenzioni specifiche, ma non ho trovato niente per quanto
> > riguarda una convenzione italiana. Quindi volevo chiedere:
> > potremmo decidere come comportarci unitariamente per questo
> > tipo
> > di convenzioni?
> > 
> > 
> > 
> > Il dubbio è nato dopo una domanda arrivata nel gruppo
> > Telegram:
> > vicino Portogruaro, precisamente in località Mazzolada, c'è
> > un'intersezione che al momento è stata creata usando
> > diversi
> > tipi di way (allegato 1). La divisione a monte della strada
> > è
> > stata fatta perché, prima dell'intersezione, è presente una
> > separazione delle due linee tramite isola zebrata (non
> > fisica,
> > quindi, ma solo dipinta; allegati 2 e 3) e, più avanti, nel
> > punto specifico dell'intersezione, è stata creata una
> > ragnatela
> > di way a senso unico (allegato 1). Da
> > qui è nata la ricerca perché: se lasciamo come ora niente
> > da
> > cambiare, ma ci teniamo una ragnatela di way; se la
> > separazione
> > tramite isola dipinta non la vogliamo considerare come una
> > separazione della strada e la strada si può mappare usando
> > una
> > sola way, bisogna ricorrere ai tag lanes.
> > 
> > 
> 
> 
> 
> Questa io la vedrei molto meglio con una sola way, quindi non
> separata. Così è un po' incasinata. Per quello che ne sapevo si
> disegna la way separata solo se fisicamente separata, tranne che
> per
> qualche rara eccezione.
> 
> 
> 
> Damjan
> 
>   
> 
> 

Anche per me è una complicazione inutile.
Anzi, volendo mappare le corsie di svolta, credo che si ottengano
risultati anche migliori utilizzando turn:lanes=* su una way singola.


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


Re: [OSM-talk] Should we map things that do not exist?

2020-05-25 Per discussione steve . barkto
On Mon, 25 May 2020 08:20:03 -0600 (GMT-06:00), Jack Armstrong
 wrote:

>Why are railways given a special status?

  One possible view is that railways were an early OSM data consumer.   In
many cases, OSM became the best resource to know current and previous rail
lines, and useful for cases to track down related historical artifacts,
plan for reuse based on slope, etc.
 OSM did render all rail lines for a time (including razed), then stopped
rendering historical items.   OpenRailwayMap has taken over rendering, but
I'm not sure if they've started transitioning to OpenHistoricalMap as a
source of purely historical items.   
  It would be handy if there was a way to delete an OSM object "into
OpenHistoricalMap" with a checkbox.


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


Re: [Talk-de] highway=crossing -> highway=traffic_signals

2020-05-25 Per discussione bergaufsee via Talk-de
Hallo,

Am 24.05.20 um 20:30 schrieb Florian Lohoff:
> Hi,
>
> On Sat, May 23, 2020 at 04:48:17PM +0200, Volker via Talk-de wrote:
>> Hat das vielleicht etwas hiermit
>> https://forum.openstreetmap.org/viewtopic.php?id=69290
>>  zu tun? Das Proposal ist allerdings
>> rejected.https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only
>> 
> Das will ich nicht ausschliessen. Kann es sein das irgendein validator
> oder QA tool das als Fehler raus wirft und änderungen Analog des
> proposals empfiehlt?

Osmose gibt das als Hinweis "*Möglicherweise* fehlende
highway=traffic_signals in der Nähe" raus
https://osmose.openstreetmap.fr/de/errors/?item=2090=2

>
> Ich sehe halt Änderungen im routing weil natürlich eine Ampelkreuzung
> anders als Fußgängerampeln bewertet werden. D.h. bestimmte routen 
> werden "länger" bzw langsamer.

Ich bevorzuge zwar auch highway=crossing + crossing=traffic_signals,
wenn aber doch jede Ampel einen highway=traffic_signals erhält, dann
sollte ein node mit crossing=traffic_signals OHNE
highway=traffic_signals sich wenigstens nicht mehr verkehrsverzögernd in
Navis bemerkbar machen und nodes mit traffic_signals=crossing_only eine
geringere Verzögerung, dann könnte es evtl. passen.

Was mich allerdings stört, wenn ein alleinstehender node
highway=crossing zu highway=traffic_signals geändert wird, dann fehlt
mir irgendwie der Fußgänger-/Radfahrerüberweg und bringt da eine
Inkonsistenz rein

Bernd




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


Re: [Talk-de] Massenweise Entfernung von oneway=no

2020-05-25 Per discussione Florian Lohoff
On Mon, May 25, 2020 at 01:08:33AM +0200, Tobias Knerr wrote:
> Meiner Meinung nach geht die Idee, Default-Werte explizit zu setzen, zu
> Lasten der Übersichtlichkeit. Die logische Konsequenz wären ja
> maxweight=none, maxheight=none, bridge=no, tunnel=no, covered=no
> access=yes vehicle=yes motor_vehicle=yes etc. an fast jeder Straße. Und
> wie mappe ich z.B., dass zwischen zwei Straßen keine Abbiegebeschränkung
> besteht – lege ich dann jeweils eine Relation mit restriction=allowed
> an? Wie mappe ich, dass an einer Stelle kein Gebäude steht, in einem
> Gebäude kein weiterer Laden mehr ist, auf dem Gehsteig kein weiterer
> Abfalleimer steht, ...?
> 
> Vielleicht etwas übertrieben, aber worauf ich hinaus will: Die
> Abwesenheit von einem Objekt oder Attribut sollte normalerweise nicht
> erfasst werden – nur in Ausnahmefällen dort, wo sie überraschend ist
> (weil es kürzlich anders war, die Luftbilder veraltet sind, es bei den
> Straßen drumherum anders ist, ...) . Wenn in deiner Gegend bestimmte
> Arten von Straßen oft "umgedreht" werden, kann das durchaus so ein Fall
> sein.

Ich überlege gerade was ist mit lit/cycleway/sidewalk/shoulder ?

So einfach ist es eben nicht. Es gibt zwar defaults die auch Sinn
machen. Es gibt dinge deren "seltenheit" macht es Unsinning eben 
den umgekehrten fall zu taggen oneway=no als Beispiel.

Aber was ist mit lit? Da sind ja sowohl lit=no wit auch lit=yes eine 
information. Und bei lit ist die Verteilung eher 80/20.

Was ist mit sidewalk=no, cycleway=no? hat ja ggfs im Routing
eine Auswirkung je nach Straßenklasse. Auf einem residential mit
sidewalk=no will ich vielleicht noch laufen. Auf einem primary mit
lit=no, sidewalk=no vermutlich eher nicht - vor allem nicht Nachts.

Also die Regel das nur weil etwas NICHT existiert wir es nicht taggen
ist zu kurz gesprungen.

Ich glaube das funktioniert im Moment nur deshalb weil jeder da seinen
Menschenverstand benutzt - oder eben auch nicht.

Ich denke man müsste für jedes tag einzeln durchgehen ob es Sinn macht
yes UND no zu taggen und wenn ja wann.

Und für einiges haben wir defaults, für anderes aber eher so nicht - bzw
eher undokumentiert und gefühlt.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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


Re: [Talk-GB] Q2 2020 Quarterly project GP Surgeries and health sites

2020-05-25 Per discussione Cj Malone via Talk-GB
I think a lot of the confusion comes from the name suggestion index (some of 
the presets for iD) listing Boots twice. However basically all (if not all) of 
Boots in the UK are pharmacies, because they do prescriptions. In some regions 
this is not the case, Boots without prescriptions is a chemist.

In the UK it's more obvious using Superdrug as an example, some stores do 
prescriptions, some don't. If Superdrug does prescriptions it may be 
amenity=pharmacy or it may have a separate node for the pharmacy, with 
different contract details and opening times, but I don't think this is usually 
worth it for small shops.

Supermarkets on the other hand, I would have there pharmacies as separate 
nodes, partly for the above, different details. But also because the location 
inside the store can be massively helpful for people who just want the 
pharmacy, not the supermarket. See Sainsbury's with a Lloyds Pharmacy inside it 
https://www.openstreetmap.org/node/6868601075 Tesco with a Tesco pharmacy 
inside https://www.openstreetmap.org/node/6841571554

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


Re: [Talk-it] Separazione strade

2020-05-25 Per discussione Damjan Gerl

  
  
Manuel je 25.5.2020 ob 14:51 napisal:


  
  Sulla Wiki ho notato che esistono due diverse convenzioni
per quanto riguarda la separazione delle ways: una prende in
considerazione le divisioni fisiche (barriere, isole di
traffico, ecc.), mentre l'altra prende in considerazioni anche
separazioni de facto (come per esempio una linea doppia
continua prima di una separazione). Sulla
  Wiki viene indicato che potrebbero esserci delle
convenzioni specifiche, ma non ho trovato niente per quanto
riguarda una convenzione italiana. Quindi volevo chiedere:
potremmo decidere come comportarci unitariamente per questo tipo
di convenzioni?

Il dubbio è nato dopo una domanda arrivata nel gruppo Telegram:
vicino Portogruaro, precisamente in località Mazzolada, c'è
un'intersezione che al momento è stata creata usando diversi
tipi di way (allegato 1). La divisione a monte della strada è
stata fatta perché, prima dell'intersezione, è presente una
separazione delle due linee tramite isola zebrata (non fisica,
quindi, ma solo dipinta; allegati 2 e 3) e, più avanti, nel
punto specifico dell'intersezione, è stata creata una ragnatela
di way a senso unico (allegato 1). Da
qui è nata la ricerca perché: se lasciamo come ora niente da
cambiare, ma ci teniamo una ragnatela di way; se la separazione
tramite isola dipinta non la vogliamo considerare come una
separazione della strada e la strada si può mappare usando una
sola way, bisogna ricorrere ai tag lanes.


Questa io la vedrei molto meglio con una sola way, quindi non
separata. Così è un po' incasinata. Per quello che ne sapevo si
disegna la way separata solo se fisicamente separata, tranne che per
qualche rara eccezione.

Damjan
  


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


Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

2020-05-25 Per discussione Florian Lohoff

Hi Colin,

On Mon, May 25, 2020 at 10:54:46AM +0200, Colin Smale wrote:
> > You cant tell whether this access=private is okay to break, and the
> > other not.
> 
> "private" is not the same as "no". It simply means that the owner has
> the right to decide who to admit, and the default is "no access" unless
> you have explicit or implicit permission from the owner. 

For some/all routers it is. At least for my QA stuff i use OSRM
with default car profile has private -> no. It on the access
restrictions blacklist.

Those ways basically drop of the graph. Which is IMHO correct.
We/Technology cant decide whether we fall into that category of beeing
allowed to traverse that specific part of the road network. So
technology has to refrain from using it.

> With respect to private driveways, they are simply private. The owner
> will tolerate friends and neighbours, postmen, delivery drivers etc
> coming to the door - you could say they have implicit permission. A
> random person however has no implicit permission and must keep out. 

No - I see this behaviour more as "permissive" - Because you dont have a
blacklist until you find somebody to deny access.

On the opposite private is "Everybody is on the blacklist with some 
exceptions". This is not the way a default driveway works.

You implicitly allow anyone visiting you to use it, until somebody
shouts at you.
 
> In Germany it sounds like it is the same as it is here in the
> Netherlands. If you don't put up a sign saying "keep out" or equivalent,
> no actual offence is committed by passing the sign onto your land.
> However you, as the land owner, have the sole right to erect such a sign
> at your discretion and to make the rules as you see fit. 

Correct - But thats a legalese of private property. So its a matter of
ownership not a per se access restriction. Access restrictions come into
the game as soon as there is a visible intention e.g. "Keep out" "No
trespassing" or even some physical barrier (Which might be a simple
rope)
 
> There is also the category "access=permissive" which is in the middle.
> You have no statutory right to access the land, however the owner has
> clearly decided to allow the public access (i.e. everybody has implicit
> permission). The owner can (in theory at least) rescind that implied
> easement at any time or otherwise restrict access.

permissive is the opposite of private.

permissive  -> Anyone until further notice
private -> Noone until further notice

And driveways are for welcoming people you most certainly dont know in
advance. So a driveway by behaviour is not private unless you explicitly
want it that way.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-se] Samordning, dokumention & olika kommunikationskanaler

2020-05-25 Per discussione Mattias Axell
Hej!

Håller med om förslaget att använda Matrix.org -protokollet (Riot.im)
som snabb kommunikationskanal. Också för att jag tänker mig att det kan
finnas intresse hos flera då det går att drifta och delta via egen
Matrix-server och identitetsserver. Dessutom finns det trevliga bryggor
driftade i Sverige som kan brygga in XMPP och IRC t.ex. via
https://linux.pizza/

Jag håller med föregående meddelande och tror också att:
- wikin kan vara potentiellt viktig plats för dokumentation men
förutsättningen är att det är tydligt hur wikin ska skrivas.
- Jag tror också att om ett Forum ska användas så kan en instans av
Discourse.org vara lämplig. Och jag tror att ett forum lämpar sig bättre
än en mejlinglista, bland annat för att Discourse kan funka som
mejlinglista fast kring de trådar man är involverad i. Det är trevligt
för att slippa blanda olika topics. Ett exempel på forum-användning med
Discourse som jag gillar är Edgeryders https://edgeryders.eu/.
- Wikimedia Sverige erbjudit sig att stötta formalisering och
strukturering av OSM i Sverige?

Mvh,
Mattias

On 2020-05-24 23:30, talk-se-requ...@openstreetmap.org wrote:
> Send Talk-se mailing list submissions to
>   talk-se@openstreetmap.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.openstreetmap.org/listinfo/talk-se
> or, via email, send a message with subject or body 'help' to
>   talk-se-requ...@openstreetmap.org
> 
> You can reach the person managing the list at
>   talk-se-ow...@openstreetmap.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-se digest..."
> 
> 
> Today's Topics:
> 
>1. Re: Samordning, dokumention & olika kommunikationskanaler
>   (tomasy -)
>2. Re: Samordning, dokumention & olika kommunikationskanaler
>   (Andreas Vilén)
> 
> 
> --
> 
> Message: 1
> Date: Sat, 23 May 2020 18:49:29 +0200
> From: tomasy - 
> To: talk-se@openstreetmap.org
> Subject: Re: [Talk-se] Samordning, dokumention & olika
>   kommunikationskanaler
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Som snabb kommunikationskanal föreslår jag *Riot* https://about.riot.im/
> Det är en opensource tjänst som inte sprider personlig data. Påminner om
> Slack. Man kan föra diskussion i trådar. Det går att dela filer och bilder.
> Fler och fler opensource-projekt använder Riot. Kan köras i browser men det
> finns även appar för Android (Google och F-Droid), Appstore, Windows och
> Linux. Mozilla har flyttat från IRC till Riot och efter 4 månader har de
> 4-10 * mer medlemmar på sina grupper .
> https://discourse.mozilla.org/t/updates-to-chat-mozilla-org-e2e-encryption-by-default-nicer-ui-email-notifications-and-sso-fixes/60425.
> En del openstreetmap grupper finns redan där.
> 
> Nackdelen med Riot är att man inte har samma tydliga trådar som t.ex.
> forumet eller maillinglistan.
> 
> Varför inte...
> *Facebook*. Alla vill inte vara med i Facebook pga. att de samlar personlig
> data.
> *IRC*. Gammalt system som fler och fler går ifrån. Ingen historik.
> *Mailinglista* Bra att hitta trådarna efteråt men inte bra för snabb
> kommunikation.
> /tomasy
> On 2020-05-16 11:22, Daniel Westergren wrote:
> 
> Tjenare,
> 
> En fråga som nog bättre lämpar sig att föra i den här mailinglistan än i
> Facebook-gruppen, då det inte är en enkel fråga utan kräver en
> djupare diskussion.
> 
> Frågeställningen rör vilka kanaler som är lämpligast för olika typer av
> diskussioner med det svenska OSM-communityt och hur vi samordnar vad som
> finns i wikin, där ju all viktig dokumentation bör samlas.
> 
> *Befintliga kanaler*
> Enligt kommentarer i FB-gruppen är forumet
>  egentligen bäst att
> använda för diskussioner, fast det används inte. Alltså är det inte bra.
> Likväl skrivs det frågor där, men de får sällan svar.
> 
> I andra hand *mailinglistan*, eftersom där sparas historiken garanterat (om
> än i en 90-talsinsinspirerad, antik lösning). Någon har även skrivit här i
> mailinglistan att de föredrar det, då de inte är med i FB-gruppen.
> 
> Men *Facebook-gruppen* är bra för snabbare diskussioner som inte är lika
> djupa, med enkla frågor och svar.
> 
> Dokumentationen ska sedan ske i *wikin*. Men det finns ingen som ansvarar
> för eller har en strategi för hur den ska underhållas och uppdateras för
> att faktiskt vara aktuell. Dessutom oklart vad vi behöver skriva på svenska
> och när det räcker med att hänvisa till det som finns på engelska.
> 
> Och så finns det kanske nån *IRC-kanal* om folk fortfarande använder sådant
> 2020?
> 
> En klassisk open source-röra med andra ord...
> 
> *Vad kan vi göra?*
> Till att börja med, *kan vi inte i alla de här kanalerna hänvisa till vilka
> kanaler som finns och vad de lämpligast används för?*
> 
>- I beskrivningen för FB-gruppen länkar vi till wikin och mailinglistan
>(och 

Re: [OSM-talk] Should we map things that do not exist?

2020-05-25 Per discussione 80hnhtv4agou--- via talk

it was tagged ( proposed ), and asphalt.
 
  
>Monday, May 25, 2020 11:56 AM -05:00 from Mateusz Konieczny via talk 
>:
> 
>I would say that anyone has right to remove such objects.
> 
>I am also unsure what would even be a correct tagging. never_existed:highway=*?
> 
>(sole reason for possible keeping would be danger of accidental mapping it, but
>given that it never existed it should not appear on any aerial images)
> 
>May 25, 2020, 17:32 by talk@openstreetmap.org:
>>? should a highway never built in 2011, mapped, that goes through a farm 
>>still be there even if tagged 
>> 
>>right, and if not who has a right to remove it ?
>> 
>>>Monday, May 25, 2020 10:10 AM -05:00 from Mateusz Konieczny via talk < 
>>>talk@openstreetmap.org >:
>>> 
>>>May 25, 2020, 16:48 by colin.sm...@xs4all.nl:
On 2020-05-25 16:20, Jack Armstrong wrote:
>Why are railways given a special status?
Nobody gives anything a status in OSM. Nothing is "approved" so nothing is 
"forbidden" either.
>>>It is not really accurate - there is plenty of forbidden things (like running
>>>imports without discussion, we have tags that are silently removed by
>>>editors like iD and JOSM).
>>> 
>>>We have voted on tags that are described as "approved".
>>> 
>>>Even if " Nothing is "approved" " is true it does not mean that nothing is 
>>>forbidden.
>>> 
>>>And other ways of giving various things various kinds of status.
It is not even "forbidden" to use tags that someone has declared 
"deprecated".
>>>This is true.
 
Is there any case of a whole class of objects being removed from OSM on the 
grounds
that they "do not belong"? Who would burn their fingers on that?
>>>Depends on what you mean by "whole class of objects".
 
If we are looking to set a precedent for that it would probably be wiser to 
pick on a less controversial and emotive subject.
 
>>>We have precedent that entire classes and types of things are
>>>out of scope.
>>>___
>>>talk mailing list
>>>talk@openstreetmap.org
>>>https://lists.openstreetmap.org/listinfo/talk
>> 
>> 
>> 
>> 
> 
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk 
 
 
 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-de] Massenweise Entfernung von oneway=no

2020-05-25 Per discussione bergaufsee via Talk-de
Hallo,

Am 25.05.20 um 01:08 schrieb Tobias Knerr:
> Die logische Konsequenz wären ja
> maxweight=none, maxheight=none, bridge=no, tunnel=no, covered=no
> access=yes vehicle=yes motor_vehicle=yes etc. an fast jeder Straße. 

sehe ich auch so und daher setze ich auch nur oneway=yes, selbst auf
Radwegen wo ich die Argumentation für oneway=no noch eher nachvollziehen
kann. Ausnahmen die Sinn ergeben kann es durchaus geben, ist selbst im
wiki beispielhaft vermerkt. Und ja, ich bin mir sicher auch schon
oneway=no gelöscht zu haben an ways an denen ich eh zugange war. Ich
denke in einem Punkt sind wir uns aber einig, Massenedits sind auch hier
(ohne Ankündigung) nicht i.O.

Gruß Bernd




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


Re: [OSM-talk] Should we map things that do not exist?

2020-05-25 Per discussione Colin Smale
On 2020-05-25 18:52, Mateusz Konieczny wrote:

> Even if "Nothing is "approved"" is true it does not mean that nothing is 
> forbidden. 
> Can you name one tag that is "forbidden"? Does that mean a standing 
> instruction to all mappers to remove it whenever it is found, or a license to 
> do a seek-and-destroy across the whole database? Or does "forbidden" not 
> quite mean "may not appear in OSM"? "Frowned upon" possibly.

I would say that 

"Does that mean a standing instruction to all mappers to remove it
whenever it is found, 
or a license to do a seek-and-destroy across the whole database?" 

applies to several things (listed below). 

>> Is there any case of a whole class of objects being removed from OSM on the 
>> grounds  
>> that they "do not belong"? Who would burn their fingers on that? 
>> Depends on what you mean by "whole class of objects".
> 
> Class, category, whatever... A subset of the objects in the OSM data with 
> common characteristics. 
> 
>> If we are looking to set a precedent for that it would probably be wiser to 
>> pick on a less controversial and emotive subject. 
>> 
>> We have precedent that entire classes and types of things are 
>> out of scope.
> 
> Where is that written down? What classes and types of things have been 
> declared out of scope?

For example things that I immediately remember 

- fictional objects 
- blatantly subjective things like reviews, ratings 
- mapping of private objects (location of my bed) 
- mapping of moving objects (location of myself or a moving ship or
plane) 
- completely gone objects (for railways the question is when railway is
fully gone) 
- personal detail (ties into subjective ones) like "my favorite trees",
or "towns I visited" 
- objects on Moon/Mars and other locations outside Earth 

Objects with these characteristics cannot be (easily) identified in the
data - they would need a human to judge on a case-by-case basis (except
for the extra-terrestrial things, but you might have trouble defining
their location in terms of WGS84 lat/lon anyway...) 

Subjective data is by definition not independently verifiable, so that
can go. Ratings are sometimes awarded by a recognised body (rather than
by customers), and those ratings would IMHO qualify as independently
verifiable.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Per discussione Yves P.
> il n'y a pas besoin de tableau pour lister 3-4 abréciations, parler de
> l'espace et de capitale<>minuscule, au contraire les tableaux de 26
> lignes pourêtre ultra complet, sont hyper lourd parce qu'on passe
> son temps à les lire croyant qu'il y a une info particulière
> autre que le déluge

Pas sur d'avoir tout saisi. Je parlais du tableau dans la page wiki addr, pas 
d'un nouveau tableau listant tout les cas :)

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


Re: [OSM-talk] Should we map things that do not exist?

2020-05-25 Per discussione Mateusz Konieczny via talk
I would say that anyone has right to remove such objects.

I am also unsure what would even be a correct tagging. never_existed:highway=*?

(sole reason for possible keeping would be danger of accidental mapping it, but
given that it never existed it should not appear on any aerial images)

May 25, 2020, 17:32 by talk@openstreetmap.org:

> ? should a highway never built in 2011, mapped, that goes through a farm 
> still be there even if tagged 
>  
> right, and if not who has a right to remove it ?
>  
>
>> Monday, May 25, 2020 10:10 AM -05:00 from Mateusz Konieczny via talk 
>> :
>>  
>> May 25, 2020, 16:48 by colin.sm...@xs4all.nl:
>>
>>>
>>> On 2020-05-25 16:20, Jack Armstrong wrote:
>>>
>>>
 Why are railways given a special status?

>>> Nobody gives anything a status in OSM. Nothing is "approved" so nothing is 
>>> "forbidden" either.
>>>
>> It is not really accurate - there is plenty of forbidden things (like running
>> imports without discussion, we have tags that are silently removed by
>> editors like iD and JOSM).
>>  
>> We have voted on tags that are described as "approved".
>>  
>> Even if ">> Nothing is "approved">> " is true it does not mean that nothing 
>> is forbidden.
>>  
>> And other ways of giving various things various kinds of status.
>>
>>> It is not even "forbidden" to use tags that someone has declared 
>>> "deprecated".
>>>
>> This is true.
>>
>>>  
>>> Is there any case of a whole class of objects being removed from OSM on the 
>>> grounds
>>> that they "do not belong"? Who would burn their fingers on that?
>>>
>> Depends on what you mean by "whole class of objects".
>>
>>>  
>>> If we are looking to set a precedent for that it would probably be wiser to 
>>> pick on a less controversial and emotive subject.
>>>  
>>>
>> We have precedent that entire classes and types of things are
>> out of scope.
>> ___
>> talk mailing list
>> talk@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk
>>
>  
>  
>  
>  
>

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


Re: [OSM-talk-fr] "Les bons termes" [était Re: Import de points d'eau incendie en Saône-et-Loire]

2020-05-25 Per discussione Yves P.
Bonjour,

Dans un autre message, je redécouvre MapContrib  
et sa quête sur les bornes à incendie 
 :)

Mauvaise nouvelles : les traductions françaises n'utilisent pas les "bons 
termes" 

Bonne nouvelle : si j'ai bien compris le code source, le système de preset d'iD 
est importé ainsi que ses traductions.
Il "suffit" donc de mettre à jour tout ça à l'aide du script importIdPresets.js 

 
(En ayant préalablement corrigé les traductions françaises d'iD)

> Il y a dans les "presets" d'iD un système de synonymes. On peut y mettre le 
> jargon des "pros".
>>  dans les traductions d'iD, …).
>> 
> https://www.transifex.com/openstreetmap/id-editor/ 
> https://translations.launchpad.net/josm/trunk/+pots/josm/fr/+translate?batch=10=all=hydrant
>  
> 

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


Re: [OSM-talk] Should we map things that do not exist?

2020-05-25 Per discussione Mateusz Konieczny via talk



May 25, 2020, 17:34 by colin.sm...@xs4all.nl:

>
> On 2020-05-25 17:08, Mateusz Konieczny via talk wrote:
>
>
>> May 25, 2020, 16:48 by colin.sm...@xs4all.nl:
>>
>>>
>>> On 2020-05-25 16:20, Jack Armstrong wrote:
>>>
>>>
 Why are railways given a special status?

>>> Nobody gives anything a status in OSM. Nothing is "approved" so nothing is 
>>> "forbidden" either.
>>>
>> It is not really accurate - there is plenty of forbidden things (like running
>> imports without discussion, we have tags that are silently removed by
>> editors like iD and JOSM).
>>
> Doing imports without discussion more about the process, and less about the 
> details of the result. An import can be declared "bad" for many reasons.
>  
> If iD and JOSM remove certain tags when they are encountered, that is 
> different from removing whole objects.
>
OK, though that is much narrower than "Nothing is "approved" so nothing is 
"forbidden" either."
claim.

>> We have voted on tags that are described as "approved".
>>  
>> Even if ">> Nothing is "approved">> " is true it does not mean that nothing 
>> is forbidden.
>>
> Can you name one tag that is "forbidden"? Does that mean a standing 
> instruction to all mappers to remove it whenever it is found, or a license to 
> do a seek-and-destroy across the whole database? Or does "forbidden" not 
> quite mean "may not appear in OSM"? "Frowned upon" possibly.
>
I would say that

"Does that mean a standing instruction to all mappers to remove it whenever it 
is found,
or a license to do a seek-and-destroy across the whole database?"

applies to several things (listed below).

>> Is there any case of a whole class of objects being removed from OSM on the 
>> grounds 
>> that they "do not belong"? Who would burn their fingers on that?
>> Depends on what you mean by "whole class of objects".
>>
> Class, category, whatever... A subset of the objects in the OSM data with 
> common characteristics.
>  
>
>>  
>> If we are looking to set a precedent for that it would probably be wiser to 
>> pick on a less controversial and emotive subject.
>>  
>> We have precedent that entire classes and types of things are
>> out of scope.
>>
> Where is that written down? What classes and types of things have been 
> declared out of scope? 
>
For example things that I immediately remember

- fictional objects
- blatantly subjective things like reviews, ratings
- mapping of private objects (location of my bed)
- mapping of moving objects (location of myself or a moving ship or plane)
- completely gone objects (for railways the question is when railway is fully 
gone)
- personal detail (ties into subjective ones) like "my favorite trees", or 
"towns I visited"
- objects on Moon/Mars and other locations outside Earth

there is more of that - listed here is what I immediately remembered.

> Any record of a transparent process that led to that?

Not sure if there was any formal process to establish that for
example we are not mapping fictional objects.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Per discussione Marc M.
Le 25.05.20 à 17:29, Yves P. a écrit :
> le tableau risque d'être surchargé

il n'y a pas besoin de tableau pour lister 3-4 abréciations, parler de
l'espace et de capitale<>minuscule, au contraire les tableaux de 26
lignes pourêtre ultra complet, sont hyper lourd parce qu'on passe
son temps à les lire croyant qu'il y a une info particulière
autre que le déluge

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


Re: [OSM-talk-fr] Restaurant d'entreprise

2020-05-25 Per discussione Marc M.
Bonjour,

Le 25.05.20 à 16:07, Florian LAINEZ a écrit :
> Hello,
> Je me demande comment mapper un restaurant d'entreprise, 
> c'est à dire une cantine uniquement accessible aux salariés.
> Pour l'instant j'ai utilisé
> amenity=restaurant
> access=private
> qu'en pensez-vous ?

cela me semble convenir.
éventuelement en rajoutant private=employees qui a la fois
évite que quelqu'un pense que c'est une erreur et décrit
qui y a accès.

> Je n'ai pas trouvé quoi que ce soit sur le wiki,

https://wiki.openstreetmap.org/wiki/Tag:access%3Dprivate
liste le cas des parking pour employés,
tu peux éventuelement rajouter le cas du resto

> il faudrait préciser les possibilités d'accès

Mais tous ne sont pas interdit aux non employés.

Cordialement,
Marc

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


Re: [OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Per discussione forums+osm

Le 25/05/2020 à 17:29, Yves P. a écrit :


*mot*   *nombre*
bis 	18644 
 

ter 	2925 
 

quarter 	408 
 

quinter 	9 
 

quinquies 	9 
 

sexies 	3 
 

septies 	0 
 

octies 	0 
 




Je compte aussi les A, B, C…
*suffixe*   *nombre*
A   163709
B   115848
C   65820
D   46242
E   
F   28011
G   59397
H   30337
I   
J   9235
K   43749
L   
M   
N   
O   
P   
Q   
R   
S   
T   
U   
V   
W   
X   
Y   
Z   220 




Une petite remarque sur les comptages : l'utilisateur Globeur 
 semble avoir fait, ou faire 
encore, un import en masse des numéros d'adresse un peu partout, à 
partir du Cadastre, sans vérifications ni intégration aux relations 
associatedStreet existantes ; j'ai constaté cela dans mon coin. Du coup, 
les comptages sont un plus proches des infos données par le Cadastre et 
reflètent moins un contrôle humain.



À+

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


Re: [OSM-talk-fr] [OSM-Talk-fr] Restaurant d'entreprise

2020-05-25 Per discussione Philippe Verdy
access=private impossible certes, mais ce ne sont pas des restaux ouverts
sans condition (même en payant plein pôt): il peut être nécessaire de
réserver malgré tout afin d'assurer le service pour ceux dont le repas est
prépayé ou subventionné en partie; les places "libres" sont dépendantes de
l'activité des entreprises adhérentes au service, celles-ci ayant un accès
prioritaire aux réservations faites de façon planifiée de longue date et
pour lesquelles le service de restauration peut planifier aussi son
personnel et ses commandes. Imaginons qu'une grosse entreprise adhérente
prévoit que plus de la moité de son personnel sera en congé, elle en
informe le service à l'avance qui peut à loisir ensuite décider soit de
réduire son service, soit si c'est pour une courte durée, laisser un accès
libre à plus de réservations pour des tiers de passage; le jour dit, si la
fréquentation mesurée n'atteint pas l'objectif, des tiers peuvent être
autorisés à entrer dans réservation pour compléter le service par des accès
libres (même si c'est à tarif "plein pôt"). Un tel service est tenu
d'afficher ses prix, que ce soit pour les utilisateurs réguliers des
entreprises abonnées et payent le tarif réduit, ou le tarif complet (ou le
montant du droit forfaitaire d'accès ajouté pour les non abonnés aux prix
réduits affichés).

Nombre de ces restaurants en revanche ne distinguent pas les prix des
services facultatifs non subventionnés (exemple: les boissons, hors
quelques unes comme l'eau gratuite hors bouteille, ou les ventes de
produits à emporter et tout ce qui est hors du menu de base subventionné et
affiché: si les visiteurs ne veulent pas de ce menu ou des produits de
substitution en cas de rupture s'il arrivent tard après l'affluence, ils
peuvent toujours acheter ces produits à emporter ou produits hors menus,
avec une éventuelle réduction tenant compte de leur abonnement, ou aller
manger ailleurs dans le secteur commercial libre, avec leurs éventuels
tickets restaurants s'ils en ont). La garantie d'être servi correctement
avec le menu subventionné ne tient plus si les abonnés arrivent trop tard
en fin de service, cela a pu être déjà servis aux non-abonnés quand le
quota minimum d'abonnés a déjà été servi et qu'il n'y a pas d'autres
réservations attendues encore à servir.

Bref cela reste du semi-privé, tout le monde ne peut pas se présenter à
n'importe quelle heure du service et sans réserver (ces restos acceptent
souvent les réservations la veille mais le jour même pour le service de
midi c'est trop tard, aucune garantie qu'ils pourront manger s'ils se
présentent, ils peuvent essayer mais on pourra leur dire que le service est
complet même s'il reste encore de quoi servir d'autres). De plus ces restos
ont des politiques antigaspillage: ce qui reste en fin de service est
souvent réutilisé pour le service suivant et autant que possible pas jeté,
quitte à ce que la cuisine reconfectionne de nouveaux plats avec les restes
(les fruits peuvent servir pour les salades, la viande, les rotis, poulets
pour des hachis ou des salades froides, les légumes cuits et le riz pour
les salades froides sur le buffet, les pommes de terre pour des purées, des
soupes, des sauces, il n'y a que les fritures qui sont jetées mais il y en
a très peu car elle se font au fur et à mesure; les grillades sont presque
toujours à partir de surgelés et faits quasiment à la demande, il reste le
problème du pain qui ne sera pas forcement mangeable le lendemain ou après
un weekend, mais il y a un recyclage vers l'alimentation animale, et
parfois des dons aux assos qui peuvent récupérer aussi des barquettes prêts
à servir que le resto préparera dans l'après-midi et mettra à disposition
avant la fin de journée).

Le lun. 25 mai 2020 à 16:49, Francescu GAROBY  a écrit :

> Bonjour,
> Dans le dernier cas que cite Philippe, le restaurant d'entreprise est
> alors accessibles à tous, la seule différence étant la tarification : les
> entreprises qui contribuent au financement du restaurant interentreprises
> subventionnent en fait le repas de leurs employés. Les autres (gens de
> l'extérieur au site ou d'entreprises qui ne financent pas) payent plein pot.
> Je dis ça parce que ça signifie que le tag "access=private" est alors
> impossible, dans ce cas.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] [OSM-Talk-fr] Restaurant d'entreprise

2020-05-25 Per discussione Florian_G

Hello,

Le lun. 25 mai 2020 à 16:08, Florian LAINEZ > a écrit :
Je me demande comment mapper un restaurant d'entreprise, c'est à dire 
une cantine uniquement accessible aux salariés.

Pour l'instant j'ai utilisé
amenity=restaurant
access=private


Je fais à peu près pareil (p. ex. : 
https://www.openstreetmap.org/node/6953735390, 
https://www.openstreetmap.org/node/6366382079 ou 
https://www.openstreetmap.org/node/6691321281), à ceci près que j'ai 
choisi "access=destination" car l'entrée n'est pas autorisée qu'au 
personnel de l'entreprise hôte ou à ses prestataires permanents (donc 
avec un badge pour le restaurant d'entreprise) mais aussi aux externes, 
aux employés d'autres sites ou aux invités qui ont un badge d'accès au 
bâtiment.


Par contre, j'hésite entre "amenity=restaurant" et "amenity=fast_food + 
fast_food=cafeteria". Je suis preneur d'idées également. Dans les 3 cas 
ci-dessus, ce sont des self, pas de service à table.


Le 25/05/2020 à 16:48, Francescu GAROBY a écrit :
Dans le dernier cas que cite Philippe, le restaurant d'entreprise est 
alors accessibles à tous, la seule différence étant la tarification : 
les entreprises qui contribuent au financement du restaurant 
interentreprises subventionnent en fait le repas de leurs employés. 
Les autres (gens de l'extérieur au site ou d'entreprises qui ne 
financent pas) payent plein pot.
Je dis ça parce que ça signifie que le tag "access=private" est alors 
impossible, dans ce cas.


Voilà, d'où mon choix de "access=destination" : ceux qui ont "le droit" 
d'aller y déjeuner.



À+

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


Re: [OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Per discussione osm . sanspourriel

Le 25/05/2020 à 14:01, Yves P. - yves.prat...@gmail.com a écrit :


Est-ce que ça fonctionne si on met un espace insécable ?
Ou ça complique la saisie/recherche dans nominatim… ?


Tu veux sans doute dire un*e*

espace.

J'ai fait une recherche :

1bis rue de la mairie, Nominatim trouve des 1BIS, pas de 1 bis. 1B au
cadastre

1 bis rue de la mairie, Nominatim trouve des 1 bis, 1 BIS, pas de 1BIS.
1B au cadastre

Alors si tu veux en plus le perdre avec des signes typographiques
spéciaux...

N. B. : oui les espaces sont naturellement insécables mais comme c'est
une règle pour les références,

Sur Wikipédia
, ils
semblent attacher (0bis).

Sur ma com com ils mettent d'un côté le numéro et de l'autre le
"suffixe" : bis en minuscule et en entier.

Et FR:Key:addr  donne
pour exemple 12b;12c. Oui en minuscules ! La version anglaise ne dit rien.

Jean-Yvon

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


Re: [OSM-talk] Should we map things that do not exist?

2020-05-25 Per discussione Colin Smale
On 2020-05-25 17:08, Mateusz Konieczny via talk wrote:

> May 25, 2020, 16:48 by colin.sm...@xs4all.nl: 
> 
> On 2020-05-25 16:20, Jack Armstrong wrote: 
> 
> Why are railways given a special status? 
> 
> Nobody gives anything a status in OSM. Nothing is "approved" so nothing is 
> "forbidden" either.

It is not really accurate - there is plenty of forbidden things (like
running 
imports without discussion, we have tags that are silently removed by 
editors like iD and JOSM). 
Doing imports without discussion more about the process, and less about
the details of the result. An import can be declared "bad" for many
reasons. 

If iD and JOSM remove certain tags when they are encountered, that is
different from removing whole objects. 

> We have voted on tags that are described as "approved". 
> 
> Even if "Nothing is "approved"" is true it does not mean that nothing is 
> forbidden.

Can you name one tag that is "forbidden"? Does that mean a standing
instruction to all mappers to remove it whenever it is found, or a
license to do a seek-and-destroy across the whole database? Or does
"forbidden" not quite mean "may not appear in OSM"? "Frowned upon"
possibly. 

> Is there any case of a whole class of objects being removed from OSM on the 
> grounds  
> that they "do not belong"? Who would burn their fingers on that? 
> Depends on what you mean by "whole class of objects".

Class, category, whatever... A subset of the objects in the OSM data
with common characteristics. 

> If we are looking to set a precedent for that it would probably be wiser to 
> pick on a less controversial and emotive subject. 
> 
> We have precedent that entire classes and types of things are 
> out of scope.

Where is that written down? What classes and types of things have been
declared out of scope? Any record of a transparent process that led to
that?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-it] Negozio di vendita e affilatura coltelli

2020-05-25 Per discussione alepoz via Talk-it
Ringrazio tutti per i vati suggerimenti. Sono propenso ad usare lo schema 
proposto da Giovanni Cascafico, vale a dire l'etichettatura come ferramenta 
specializzato in lame. Come già spiegato, esclusa la parentela con l'armeria, 
perché nel negozio non vengono trattati coltelli da caccia. Nemmeno l'etichetta 
da negozio di posate sarebbe adatta.

Procedo.


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


Re: [OSM-talk] Should we map things that do not exist?

2020-05-25 Per discussione 80hnhtv4agou--- via talk

? should a highway never built in 2011, mapped, that goes through a farm still 
be there even if tagged 
 
right, and if not who has a right to remove it ?
  
>Monday, May 25, 2020 10:10 AM -05:00 from Mateusz Konieczny via talk 
>:
> 
>May 25, 2020, 16:48 by colin.sm...@xs4all.nl:
>>On 2020-05-25 16:20, Jack Armstrong wrote:
>>>Why are railways given a special status?
>>Nobody gives anything a status in OSM. Nothing is "approved" so nothing is 
>>"forbidden" either.
>It is not really accurate - there is plenty of forbidden things (like running
>imports without discussion, we have tags that are silently removed by
>editors like iD and JOSM).
> 
>We have voted on tags that are described as "approved".
> 
>Even if " Nothing is "approved" " is true it does not mean that nothing is 
>forbidden.
> 
>And other ways of giving various things various kinds of status.
>>It is not even "forbidden" to use tags that someone has declared "deprecated".
>This is true.
>> 
>>Is there any case of a whole class of objects being removed from OSM on the 
>>grounds 
>>that they "do not belong"? Who would burn their fingers on that?
>Depends on what you mean by "whole class of objects".
>> 
>>If we are looking to set a precedent for that it would probably be wiser to 
>>pick on a less controversial and emotive subject.
>> 
>We have precedent that entire classes and types of things are
>out of scope.
>___
>talk mailing list
>talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk 
 
 
 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Per discussione Yves P.
> @yves On a abordé ce sujet il y a peu de temps.
Merci pour le lien 
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg96547.html 


mot nombre
bis 18644 

ter 2925 

quarter 408 

quinter 9 

quinquies   9 

sexies  3 

septies 0 

octies  0 


Je compte aussi les A, B, C…
suffixe nombre
A   163709
B   115848
C   65820
D   46242
E   
F   28011
G   59397
H   30337
I   
J   9235
K   43749
L   
M   
N   
O   
P   
Q   
R   
S   
T   
U   
V   
W   
X   
Y   
Z   220 
Les valeurs manquantes sont impossible a déterminées avec taginfo (pas de 
regex).
On peut les compter avec overpass (mais on dépasse rapidement notre quota)

> Même pour certains où c'est affiché 6 B sur le terrain il y a des cas où 
> c'est en réalité 6 Bis.

Pour différencier un B d'un bis :
A, B, C… → B
B, T, Q… → bis

> comme on peut aussi voir 266 6 pour 266sexies
Il faudrait compter toutes les variantes avec des expressions rationnelles ;)

> La Proposition de @cquest est de mettre tout en minuscule sans espace. 
> Concernant les lettres des bâtiments (ou entrée) en capitales
> Par opposition aux lettres des entrées de bâtiments qui donne droit à un 
> adressage en 1A, 1B, 1C…
Alors bis ou BIS ?
Espace ou non ?

>  On devrait mettre ça au clair sur le wiki. C'est un sujet récurrent.
Oui.
Par contre le tableau risque d'être surchargé. On enlève la redirection de 
addr:housenumber 
 vers 
addr  ?

On pourrait aussi mettre une expression rationnelle de validation dans les 
dataitems :
https://wiki.openstreetmap.org/wiki/Item:Q43
(Je ne sais plus s! ça se fait déjà ?)

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


Re: [OSM-talk] Should we map things that do not exist?

2020-05-25 Per discussione Mateusz Konieczny via talk
May 25, 2020, 16:48 by colin.sm...@xs4all.nl:

>
> On 2020-05-25 16:20, Jack Armstrong wrote:
>
>
>> Why are railways given a special status?
>>
> Nobody gives anything a status in OSM. Nothing is "approved" so nothing is 
> "forbidden" either.
>
It is not really accurate - there is plenty of forbidden things (like running
imports without discussion, we have tags that are silently removed by
editors like iD and JOSM).

We have voted on tags that are described as "approved".

Even if "Nothing is "approved"" is true it does not mean that nothing is 
forbidden.

And other ways of giving various things various kinds of status.

> It is not even "forbidden" to use tags that someone has declared "deprecated".
>
This is true.

>  
> Is there any case of a whole class of objects being removed from OSM on the 
> grounds 
> that they "do not belong"? Who would burn their fingers on that?
>
Depends on what you mean by "whole class of objects".

>  
> If we are looking to set a precedent for that it would probably be wiser to 
> pick on a less controversial and emotive subject.
>  
>
We have precedent that entire classes and types of things are
out of scope.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Should we map things that do not exist?

2020-05-25 Per discussione Colin Smale
On 2020-05-25 16:20, Jack Armstrong wrote:

> Why are railways given a special status?

Nobody gives anything a status in OSM. Nothing is "approved" so nothing
is "forbidden" either. It is either used, or it is not used. It is not
even "forbidden" to use tags that someone has declared "deprecated". 

Is there any case of a whole class of objects being removed from OSM on
the grounds that they "do not belong"? Who would burn their fingers on
that? 

If we are looking to set a precedent for that it would probably be wiser
to pick on a less controversial and emotive subject.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk-fr] [OSM-Talk-fr] Restaurant d'entreprise

2020-05-25 Per discussione Francescu GAROBY
Bonjour,
Dans le dernier cas que cite Philippe, le restaurant d'entreprise est alors
accessibles à tous, la seule différence étant la tarification : les
entreprises qui contribuent au financement du restaurant interentreprises
subventionnent en fait le repas de leurs employés. Les autres (gens de
l'extérieur au site ou d'entreprises qui ne financent pas) payent plein pot.
Je dis ça parce que ça signifie que le tag "access=private" est alors
impossible, dans ce cas.

Francescu

Le lun. 25 mai 2020 à 16:44, Philippe Verdy  a écrit :

> Note: ces restos sont très souvent multi-entreprises: une entreprise
> accueille et gère le plus gros, mais des entreprises locales voisines
> négocient des conditions d'accès aussi pour leurs propres salariés (et
> invités) (exemple à Neuilly sur l'île de la Jatte, un resto partagé étant
> dans les locaux d'une société de publicité et utilisé aussi par une
> douzaine d'autres plus petites entreprises alentours).
>
> Tout le monde y gagne, par un effet de réduction d'échelle; cela permet
> d'employer des cuisiniers toute l'année et à temps plein, d'enrichir les
> menus à moins cher avec des quantités préparées supérieures (et un
> coût moindre à l'assiette). La seule limite c'est la capacité d'accueil;
> l'entreprise hôte ne peut pas accueillir tout le monde (il faut quand même
> une carte d'accès fournie par l'entreprise hôte ou son comité d'entreprise
> avec qui les autres entreprises ont négocié l'accès et accepté d'apporter
> un financement continu toute l'année); ceci dit cela lisse aussi la
> fréquentation, il y a moins de perte, même si parfois les derniers arrivés
> devront se contenter d'un steak et des frites surgelés et pas du plat du
> jour, ni des meilleures entrées mais juste de la salade, ou n'aura plus le
> dessert du jour "fait maison", mais devra se contenter d'un yaourt sorti de
> la réserve ou de la corbeille de fruits.
>
> Bref ce sont des "semi-privés". Parfois aussi c'est un service commun à
> toute une zone d'entreprises, géré par le gestionnaire du site et non pas
> une entreprise membre particulière. Dans ce cas ce peut être délégué à une
> société spécialisée comme Sodexho qui s'occupe du recrutement du personnel
> en cuisine ou pour le service, des locaux et de tout l'approvisionnement
> (exemple à la Défense dans les "Collines de l'Arche").
>
>
>
> Le lun. 25 mai 2020 à 16:08, Florian LAINEZ  a écrit :
>
>> Hello,
>> Je me demande comment mapper un restaurant d'entreprise, c'est à dire une
>> cantine uniquement accessible aux salariés.
>> Pour l'instant j'ai utilisé
>> amenity=restaurant
>> access=private
>>
>> Exemples :
>> https://www.openstreetmap.org/node/1801525675
>> https://www.openstreetmap.org/node/1992123219
>>
>> Je ne sais pas si on a vraiment besoin d'un tag spécifique et que
>> access=private fait le taff, qu'en pensez-vous ?
>> Je n'ai pas trouvé quoi que ce soit sur le wiki, et j'ai bien envie de
>> documenter ça et de préciser les données en France.
>> En effet j'ai trouvé pas mal d'endroits avec "restaurant d'entreprise"
>> dans le name et pour lesquels je pense qu'il faudrait préciser les
>> possibilités d'accès, par exemple
>> https://www.openstreetmap.org/way/150714794
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian 
>> ___
>> 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
>


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


Re: [OSM-talk-fr] [OSM-Talk-fr] Restaurant d'entreprise

2020-05-25 Per discussione Philippe Verdy
Note: ces restos sont très souvent multi-entreprises: une entreprise
accueille et gère le plus gros, mais des entreprises locales voisines
négocient des conditions d'accès aussi pour leurs propres salariés (et
invités) (exemple à Neuilly sur l'île de la Jatte, un resto partagé étant
dans les locaux d'une société de publicité et utilisé aussi par une
douzaine d'autres plus petites entreprises alentours).

Tout le monde y gagne, par un effet de réduction d'échelle; cela permet
d'employer des cuisiniers toute l'année et à temps plein, d'enrichir les
menus à moins cher avec des quantités préparées supérieures (et un
coût moindre à l'assiette). La seule limite c'est la capacité d'accueil;
l'entreprise hôte ne peut pas accueillir tout le monde (il faut quand même
une carte d'accès fournie par l'entreprise hôte ou son comité d'entreprise
avec qui les autres entreprises ont négocié l'accès et accepté d'apporter
un financement continu toute l'année); ceci dit cela lisse aussi la
fréquentation, il y a moins de perte, même si parfois les derniers arrivés
devront se contenter d'un steak et des frites surgelés et pas du plat du
jour, ni des meilleures entrées mais juste de la salade, ou n'aura plus le
dessert du jour "fait maison", mais devra se contenter d'un yaourt sorti de
la réserve ou de la corbeille de fruits.

Bref ce sont des "semi-privés". Parfois aussi c'est un service commun à
toute une zone d'entreprises, géré par le gestionnaire du site et non pas
une entreprise membre particulière. Dans ce cas ce peut être délégué à une
société spécialisée comme Sodexho qui s'occupe du recrutement du personnel
en cuisine ou pour le service, des locaux et de tout l'approvisionnement
(exemple à la Défense dans les "Collines de l'Arche").



Le lun. 25 mai 2020 à 16:08, Florian LAINEZ  a écrit :

> Hello,
> Je me demande comment mapper un restaurant d'entreprise, c'est à dire une
> cantine uniquement accessible aux salariés.
> Pour l'instant j'ai utilisé
> amenity=restaurant
> access=private
>
> Exemples :
> https://www.openstreetmap.org/node/1801525675
> https://www.openstreetmap.org/node/1992123219
>
> Je ne sais pas si on a vraiment besoin d'un tag spécifique et que
> access=private fait le taff, qu'en pensez-vous ?
> Je n'ai pas trouvé quoi que ce soit sur le wiki, et j'ai bien envie de
> documenter ça et de préciser les données en France.
> En effet j'ai trouvé pas mal d'endroits avec "restaurant d'entreprise"
> dans le name et pour lesquels je pense qu'il faudrait préciser les
> possibilités d'accès, par exemple
> https://www.openstreetmap.org/way/150714794
>
> --
>
> *Florian Lainez*
> @overflorian 
> ___
> 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: [OSM-talk-fr] [OSM-Talk-fr] Restaurant d'entreprise

2020-05-25 Per discussione Christian Rogel
> Le 25 mai 2020 à 16:07, Florian LAINEZ  a écrit :
> 
> Je me demande comment mapper un restaurant d'entreprise, c'est à dire une 
> cantine uniquement accessible aux salariés.
> Pour l'instant j'ai utilisé
> amenity=restaurant
> access=private
> 
> Exemples :
> https://www.openstreetmap.org/node/1801525675 
> 
> https://www.openstreetmap.org/node/1992123219 
> 
> 
> Je ne sais pas si on a vraiment besoin d'un tag spécifique et que 
> access=private fait le taff, qu'en pensez-vous ?
> Je n'ai pas trouvé quoi que ce soit sur le wiki, et j'ai bien envie de 
> documenter ça et de préciser les données en France.
> En effet j'ai trouvé pas mal d'endroits avec "restaurant d'entreprise" dans 
> le name et pour lesquels je pense qu'il faudrait préciser les possibilités 
> d'accès, par exemple https://www.openstreetmap.org/way/150714794 
> 

Je me suis posé une question du même genre à propos des bibliothéques 
d’entreprises et des centre de doc internes. Je pensais que « corporate » se 
trouvait en abondance sur OSM.

En fait, non, on y trouve 2 corporate = only et autant en couple avec une 
20aine de clés. La plus farfeue (2 items) étant amenity = corporate à égalié 
avec contact:instagram = corporate.

Il y a toilets = corporate et toilets:access = corporate qui se rapprochent de 
ce qui est visé, mais 1 occurrence chacun !

J’ai exploré aussi »  internal » , mais moins de 100 mentions. Moins extensif 
que corporate.

Il y a les restaurants propres aux entreprises, mais, aussi les restaurants 
interentreprises, subdivisés en restaurants privés et restaurants 
administratifs (restaurants interentreprises gérés par une association pilotée
par une entité publique).



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


Re: [OSM-talk] Should we map things that do not exist?

2020-05-25 Per discussione Jack Armstrong
25 years ago, the Denver Stapleton Airport was closed and a new airport was built further from the city. Over 5,000 new homes were built, including schools, a library, a recreation center, over 150 shops, service businesses, restaurants and open spaces.The opinion of some users is that if nothing had been built in place of the airport, if every trace of the airport had been removed and plowed under, then OSM users should not remove anything, but simply tag all buildings, runways, service roads, parking lots, etc., with the razed tag and leave it all on the map?Why are railways given a special status? Why not tag sidewalks, buildings, and trees with the razed tag and leave them on the map? Why only keep railways as part of a historical database alongside reality-based mapping? Perhaps everything from the past that used to exist should be kept on the current map.If something has been removed and there is still something on the ground remaining, then it makes sense to map what is actually there. But, mapping something in OSM that does not exist, except in someone's mind...why should it be on a map that is supposed to reflect the current situation? As the wiki states, "Do not map objects if they do not exist currently". In the given example in Denver the (well-meaning) mapper not only mapped non-existent rails, but non-existent switches as well. The switches do not exist. The rails do not exist. It's all imaginary.

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


[OSM-talk] CyclOSM Lite a new cycling infrastructure map layer

2020-05-25 Per discussione Florimond Berthoux
Hello,

For a local project we worked on a new cycle layer map with only road
cycling infrastructure : cycle track, lane, bus lane, opposite.
The idea is to use this transparent layer over other map where full cycle
map is not desirable.

It's based on CyclOSM and a demo is available on CyclOSM.org
https://www.cyclosm.org/#map=13/45.4245/-75.6994/piano-cyclosmlite

Our local project was about mapping popup bike lanes in Paris.
https://carte.velo-iledefrance.fr/#map=12/48.8573/2.3727/OSM_Piano-Pistes_cyclables-Principaux_axes_cyclables-Pistes_cyclables_temporaires_en_projet-Pistes_cyclables_temporaires

Tiles are generated thanks to OSM-France. They are available at :
https://{s}.tile-cyclosm.openstreetmap.fr/cyclosm-lite/{z}/{x}/{y}.png
Minute generation, fill free to use it, we hope it can be useful.

Best regards.

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


Re: [OSM-talk] mspray stealth organized mapping

2020-05-25 Per discussione James Nyirenda
Greetings. I am one of the coordinators for the mSpray organized mapping.
We are aware of the issues that have been raised and we are working on them.

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


[OSM-talk-fr] [OSM-Talk-fr] Restaurant d'entreprise

2020-05-25 Per discussione Florian LAINEZ
Hello,
Je me demande comment mapper un restaurant d'entreprise, c'est à dire une
cantine uniquement accessible aux salariés.
Pour l'instant j'ai utilisé
amenity=restaurant
access=private

Exemples :
https://www.openstreetmap.org/node/1801525675
https://www.openstreetmap.org/node/1992123219

Je ne sais pas si on a vraiment besoin d'un tag spécifique et que
access=private fait le taff, qu'en pensez-vous ?
Je n'ai pas trouvé quoi que ce soit sur le wiki, et j'ai bien envie de
documenter ça et de préciser les données en France.
En effet j'ai trouvé pas mal d'endroits avec "restaurant d'entreprise" dans
le name et pour lesquels je pense qu'il faudrait préciser les possibilités
d'accès, par exemple https://www.openstreetmap.org/way/150714794

-- 

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


Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

2020-05-25 Per discussione deuzeffe

Le 25/05/2020 à 11:19, osm.sanspourr...@spamgourmet.com a écrit :


C'est moi.


Donc, tu dois les retrouver là : 
https://www.mapcontrib.xyz/t/s8c2d9-Les_bornes_a_incendie
(si ton navigateur n'abuse pas de ses prérogatives excessivement 
respectueuses des standards du web).


--
deuzeffe


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


Re: [OSM-legal-talk] Legal questions about using OSM

2020-05-25 Per discussione Birger Schütte
Hello to all!

 

I would like to apologize for asking again, but unfortunately the answer did not help me.

I realize that the use cases are not the ultimate recommendation. Therefore I had additionally relied on the 
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines.

I am examining the use of OSM in various tools - this is where these questions came up.

And therefore it would be important for me to understand from when on which kind of use of the data leads to the cases mentioned in the questions (collective, derivative and so on).
I have even interviewed a lawyer, but so far with rather little success. :-(

 

So here are my 3 most important still open questions again:
Question 1:
If I store calculated results based on OSM data in a database table (without the actual OSM data itself), such as the number of specific
POIs, travel times, travel distances and so on - the database is then a collective database, a derivative database, a "produced work", or none of them?

 

Question 2:
Does the calculation of the above described results complies with the statement: "you geocoded your data"?
 
Question 3:
If I reference other data with the data from this result database, do I have to put the referenced data under the ODBL license? For the case
that the answer to Question 1 would be collective or a "produced work"?

In case of derivative, I guess the database must be under ODBL...

 

Since I haven't had any luck deriving answers to my questions from the Community_Guidelines so far, I hope it wouldn't be too much trouble if I could possibly get answers to every single question?

Many thanks for every effort in advance!

 

Kindly Regards
Birger

 

Date: Mon, 18 May 2020 11:14:14 +0200
From: Simon Poole 
To: legal-talk@openstreetmap.org
Subject: Re: [OSM-legal-talk] Legal questions about using OSM
Message-ID: <9c917920-39c1-03c0-59a4-d0f47fc0e...@poole.ch>
Content-Type: text/plain; charset="utf-8"

You are unnecessarily making your life hard. There is a big red warning
at the top of the "Use Cases" page, simply take it seriously (the
content of that page was written in 2012 a rather long time ago and
before any of the guidelines existed). The current relevant guidelines
are available from
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines

In your specific case, as it seems you are not actually geocoding your
data (that would be extracting address or location information from OSM
with 3rd party data), that would be the Produced Work and Collective
Database guidelines.

Simon



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


Re: [OSM-talk-fr] Aménagements cyclables de déconfinement - outil carto de la FUB

2020-05-25 Per discussione deuzeffe

Le 25/05/2020 à 09:49, Laurence P a écrit :

Bonjour,


Bonjour,

pour information, cf le dernier point de la lettre de diffusion 
ci-dessous : un outil cartographique a été créé par la FUB (Fédération 
des Usagers de la Bicyclette) et de Vélo et territoires. Note pour la 
liste Association OSMFR, c'est en lien avec l'entretien qu'avait eu 
Vincent et qu'il avait évoqué dans un email.


https://www.velo-territoires.org/actualite/2020/05/20/cartographier-amenagements-cyclables-de-transition/


Je posais la question sur twitter à la suite d'un message d'OD France : 
on a les emplacements en OD des compteurs mis en place par 
Vélo ?


--
deuzeffe

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


Re: [OSM-talk] Should we map things that do not exist?

2020-05-25 Per discussione Jo
Here in Belgium many of these are repurposed as cycling highway
infrastructure. I wouldn't mind having highway=cycleway, railway=razed on
them.

Polyglot

On Mon, May 25, 2020 at 1:47 PM Mateusz Konieczny via talk <
talk@openstreetmap.org> wrote:

>
>
>
> May 25, 2020, 06:37 by jacknst...@sprynet.com:
>
> Greetings.
>
>
> Recently, a user mapped “razed” railways inside a construction zone (link
> below). These rails had been removed by our local mappers since they don’t
> exist anymore. Using the latest imagery (Maxar), you can see the rails have
> been completely removed from “Project 70”, a $1.2 billion Denver-area
> transportation corridor construction project.
>
>
> I think this mapper has good intentions, but what is the point of mapping
> something that does not exist? Doesn’t this clearly contradict the OSM Good
> Practice wiki in regards the sections, “Verifiability”, “Map what's on the
> ground” and “Don't map historic events and historic features”? The last
> section states, "*Do not map objects if they do not exist currently*."
>
> Rails were removed - but is there embankment or something similar that
> makes clear
> that railway line was there?
>
> In cases of still present embankment it is a bit tricky what is border
> between "present" and "gone".
>
> Note also that recently gone objects may be temporarily keep to prevent
> them from accidental
> remapping - for example based on old memory or old aerial images.
>
> But yes, something completely gone can and should be deleted from
> OpenStreetMap
> (temporarily kept in way that marks it as gone if likely to be
> accidentally remapped).
>
> Should we leave (invisible) destroyed buildings in place, tag them as
> razed and then create new buildings on top of them?
>
> I do this to make people using outdated aerial images less confused. And
> delete them
> once aerial images are updated.
>
> I deleted object where people were either importing old objects,
> nonexisting objects unlikely
> to be remapped by accident, supposedly existing old objects that were
> unverifiable.
>
>
> > Should we map things that do not exist?
>
> No, but remapping existing objects as "this is gone now" (building=yes ->
> demolished:building=yes)
> is often a good idea.
>
> But someone adding nonexisting railways, nonexisting buildings, historic
> boundaries and so on
> should stop, and such additions be reverted.
>
> (note that ruined buildings, ruined railways are mappable, just completely
> gone are not).
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Per discussione Jérôme Seigneuret
@yves On a abordé ce sujet il y a peu de temps. Même pour certains où c'est
affiché 6 B sur le terrain il y a des cas où c'est en réalité 6 Bis. Pareil
pour T Q...

Il faut convertir autant que possible en Bis , Ter, Quarter, Quinter. Mais
c'est aussi sur une base de connaissance. Car il existe des cas ou le 1bis
côtoie le 1B (Batiment B au 1 de la rue).
BTQ est accepté sur le terrain pour Bis , Ter, Quater . comme on peut aussi
voir *266 6* pour 266sexies

La Proposition de @cquest est de mettre tout en minuscule sans espace.
Concernant les lettres des bâtiments (ou entrée) en capitales
Par opposition aux lettres des entrées de bâtiments qui donne droit à un
adressage en 1A, 1B, 1C...


C'est abordé ici
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg96547.html
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg90355.html
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg81574.html
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg68051.html

Coté forum
https://forum.openstreetmap.fr/viewtopic.php?f=2=3260=12213=bis
#p12213

 On devrait mettre ça au clair sur le wiki. C'est un sujet récurrent.


Le lun. 25 mai 2020 à 14:10,  a écrit :

> > Je favoriserait le fait de coller les indices, car on peut facilement
> les séparer si besoin et surtout ça évite de créer une ambiguïté avec le
> reste de l'adresse comme ça peut être le cas avec un "34 A" le "A" pouvant
> être un "à...".
>
> Non, ce serait À, le cadastre respectant notoirement les accents^^.
>
> J'ai habité un bâtiment A et j'écrivais 3A, 3 A ne me choque pas, par
> contre pour bis et ter l'usage est plutôt de séparer.
>
> *Sachant que pour simplifier sur le terrain il y avait un 3, un A et un B.
> Le 3B/3 B était en face du 5A/ 5B et quand les gens viennent par l'entrée
> secondaire ils voient B et B puis A et A ;-).*
>
> J'aurais donc dit 1 bis mais 1A.
>
> J'ai regardé la plaque d'un 19 bis et il est écrit 19b...
>
> 19B et 19 bis permettrait de clarifier un peu.
>
> Et si je reprends le 3A dans un célèbre annuaire en ligne je vois 3 A, 3
> (il ne devrait y en avoir qu'un avec-entrée directe dans un appart du 3 A
> il y en a plusieurs, des 3 A, un bât 1 3 Bis - il avait dû fumer, 3 porte
> bât B). Comme ce sont les gens qui entrent ce n'est pas évident.
>
> Les références des routes comportent des espaces et donc par exemple D 342
> bis.
>
> Maintenant comme dit Christian l'essentiel est se mettre d'accord et si
> notre moulinette cadastre dit de mettre une espace, mettons la.
>
> Jean-Yvon
> Le 25/05/2020 à 13:36, Romain MEHUT - romain.me...@mailo.com a écrit :
>
> Pour mémoire :
> https://www.mail-archive.com/talk-fr@openstreetmap.org/msg81574.html
>
> Romain
>
> Le 25/05/2020 à 12:36, Marc M. a écrit :
>
> Bonjour,
>
> Le 25.05.20 à 10:28, Yves P. a écrit :
>
> Quel format faut-il utiliser ?
> 1bis, 1 bis, 1B, 1BIS, 1 BIS…
>
> http://cadastre.openstreetmap.fr dit B,T,Q→ bis, ter, quater   A→␣A
> donc "1 bis"
> mais effectivement cela devrait se trouver sur le wiki qlq part.
>
> Cordialement,
> Marc
>
> ___
> 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
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Per discussione osm . sanspourriel

> Je favoriserait le fait de coller les indices, car on peut facilement
les séparer si besoin et surtout ça évite de créer une ambiguïté avec le
reste de l'adresse comme ça peut être le cas avec un "34 A" le "A"
pouvant être un "à...".

Non, ce serait À, le cadastre respectant notoirement les accents^^.

J'ai habité un bâtiment A et j'écrivais 3A, 3 A ne me choque pas, par
contre pour bis et ter l'usage est plutôt de séparer.

/Sachant que pour simplifier sur le terrain il y avait un 3, un A et un
B. Le 3B/3 B était en face du 5A/ 5B et quand les gens viennent par
l'entrée secondaire ils voient B et B puis A et A ;-)./

J'aurais donc dit 1 bis mais 1A.

J'ai regardé la plaque d'un 19 bis et il est écrit 19b...

19B et 19 bis permettrait de clarifier un peu.

Et si je reprends le 3A dans un célèbre annuaire en ligne je vois 3 A, 3
(il ne devrait y en avoir qu'un avec-entrée directe dans un appart du 3
A il y en a plusieurs, des 3 A, un bât 1 3 Bis - il avait dû fumer, 3
porte bât B). Comme ce sont les gens qui entrent ce n'est pas évident.

Les références des routes comportent des espaces et donc par exemple D
342 bis.

Maintenant comme dit Christian l'essentiel est se mettre d'accord et si
notre moulinette cadastre dit de mettre une espace, mettons la.

Jean-Yvon

Le 25/05/2020 à 13:36, Romain MEHUT - romain.me...@mailo.com a écrit :

Pour mémoire :
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg81574.html

Romain

Le 25/05/2020 à 12:36, Marc M. a écrit :

Bonjour,

Le 25.05.20 à 10:28, Yves P. a écrit :

Quel format faut-il utiliser ?
1bis, 1 bis, 1B, 1BIS, 1 BIS…

http://cadastre.openstreetmap.fr dit B,T,Q→ bis, ter, quater A→␣A
donc "1 bis"
mais effectivement cela devrait se trouver sur le wiki qlq part.

Cordialement,
Marc

___
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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

2020-05-25 Per discussione Mateusz Konieczny via talk



May 24, 2020, 18:06 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>
>> On 24. May 2020, at 12:16, Mateusz Konieczny via talk 
>>  wrote:
>>
>> I just added some example at >> 
>> https://wiki.openstreetmap.org/wiki/Key:access
>> and improved existing one.
>>
>> Review, and improving edits (or comments here) would be welcomed.
>>
>
>
> it’s a lot of text, are you sure it improves the page to add extensive prose 
> examples? 
>
Yes. I wanted to at least try making it accessible for people starting with OSM 
tagging.
Though if there is clear opinion that examples are not helpful for anybody I 
would be fine
with deleting it (though I am pretty sure that it is helpful at least for part 
of people,
I generally love examples in documentation of various kind and AFAIK I am not 
unique).

I reverted TOC move, so long text should be now have lower negative impact.

> I have for example noted you write about “private road” as if it would imply 
> access controlled road, while the same term is commonly used also for roads 
> in private ownership (but with public access rights). The  example in this 
> case  seems to add more to the confusion than it removes.
>
This should be fixed now - can you look at it again?

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


Re: [OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Per discussione Yves P.
Merci Marc et Romain :)

> Pour mémoire : 
> https://www.mail-archive.com/talk-fr@openstreetmap.org/msg81574.html

> Je favoriserait le fait de coller les indices, car on peut facilement les
> séparer si besoin et surtout ça évite de créer une ambiguïté avec le reste
> de l'adresse comme ça peut être le cas avec un "34 A" le "A" pouvant être
> un "à...".
Bon point :)

Est-ce que ça fonctionne si on met un espace insécable ?
Ou ça complique la saisie/recherche dans nominatim… ?

> les indices de répétition (c'est leur petit nom) aux numéros.
Je ne note le nom des bis, ter, quater :)

> osmose propose plutôt "39bis"(sans espace),
> de même pour toutes les adresses contenant un "ter"
Il manque le "quater" : osmose-backend/plugins/Name_Toponymy_FR.py#L59 


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


Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

2020-05-25 Per discussione Mateusz Konieczny via talk
The problem with that is that moving examples after full specification will be 
very
effective in scaring away people who are not experts.

May 24, 2020, 15:16 by andrew.harv...@gmail.com:

> More examples are very helpful, so than you, but in my opinion the examples 
> should go near the end, at least after the specification (so list of 
> transport modes and possible values)
>
> 1. Introduction (as exists)
> 2. Full list of transport modes
> 3. List of possible values
> 4. Examples
>
> On Sun, 24 May 2020 at 20:16, Mateusz Konieczny via talk <> 
> talk@openstreetmap.org> > wrote:
>
>> I just added some example at >> 
>> https://wiki.openstreetmap.org/wiki/Key:access
>> and improved existing one.
>>
>> Review, and improving edits (or comments here) would be welcomed.
>>
>> Deliberately posting to talk to get review also from people less involved in
>> tagging discussions.
>>
>> Thanks to Malenki and Seventy7 for suggesting it (in 2009 and 2010 
>> respectively).
>> ___
>>  talk mailing list
>>  >> talk@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/talk
>>

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


Re: [OSM-talk-fr] Comment cartographier une prise électrique

2020-05-25 Per discussione Florimond Berthoux
Pour info et pour être complet il y a aussi un
amenity=device_charging_station typiquement pour les bornes de recharge de
tél dans les gares.
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Ddevice_charging_station

Le dim. 24 mai 2020 à 03:18, Marc M.  a écrit :

> Bonsoir,
>
> Le 23.05.20 à 23:50, Florimond Berthoux a écrit :
> > comment tagguer ces prises de courant ?
>
> amenity=power_supply dont la proposition a été abandonné par manque
> de temps de son auteur mais qui pourrait probablement passer avec
> quelques efforts (entre autre ne pas se prendre le tapis de la
> coexistence de charging_station)
> https://wiki.openstreetmap.org/wiki/Proposed_features/amenity=power_supply
>
> > parce que tagguer socket:typee=1 c'est peut-être overkill, non ?
>
> Si le type de prise n'est pas renseigné, on peux supposer que
> c'est la prise standard du lieu mais ce n'est qu'une supposition.
> Dans un camping cela restera ambigu vu les 3 sortes très courantes.
>
> Cordialement,
> Marc
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


Re: [Talk-GB] Road closures/changes during Covid19

2020-05-25 Per discussione Jez Nicholson
Good idea.

I know that https://www.openstreetmap.org/way/165405326 in Brighton has
been temporarily closed (in reality and in OSM).

On Sun, 24 May 2020, 15:46 Tony OSM,  wrote:

> Hi
>
> Yes a very good idea.
>
> I'm in  North West England - the main driver in this area is Manchester. I
> have seen social media  and news outlets showing photos of Deansgate,
> Manchester with expanded pedestrian areas and expanded cycle lanes; motor
> vehicles removed - but I don't know if there are delivery exceptions. This
> has been an aspiration for several years so it may become permanent.
>
> I can't travel to survey this.
>
> I have seen no mentions of expanded bicycle /pedestrian areas in Chorley
> or Preston.
>
> If a table in a wiki page was created iy region/alphabetic town - we could
> pool our knowledge and plan survey trips. Information saying no change is
> also helpful.
>
> Regards
>
> Tony
> On 24/05/2020 14:34, Rob Nickerson wrote:
>
> Hi all,
>
> How are you reflecting current road changes in OpenStreetMap? I am aware
> that some cities are closing a few roads to motor traffic and installing
> additional cycle infrastructure. I'm not sure how permanent this is going
> to be, but it certainly feels like it will last a few months.
>
> Is it worth setting up a coordinated approach to mapping these changes? We
> can set up a wiki page with a table of who is contributing in each city,
> where data is available, and what tags we want to use.
>
> Let me know what you think.
>
> Thanks,
> *Rob*
>
> ___
> Talk-GB mailing 
> listTalk-GB@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-gb
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

2020-05-25 Per discussione Mateusz Konieczny via talk



May 25, 2020, 02:56 by a...@thaw.de:

> Mateusz Konieczny via talk  wrote:
>
>>
>> I just added some example at https://wiki.openstreetmap.org/wiki/Key:access
>> and improved existing one.
>>
>> Review, and improving edits (or comments here) would be welcomed.
>>
>
>
> I disagree with moving the Table Of Contents far from the top of the page. I 
> use it for quick access to the individual chapters, and am having a hard time 
> finding it quickly. I think that especially on a page as long and complex as 
> this one, it's important that the TOC is at the top of the page, right before 
> the first header.
>
> https://wiki.openstreetmap.org/w/index.php?title=Key:access=1994648=1994635
>
TOC move was undone
https://wiki.openstreetmap.org/w/index.php?title=Key:access=1994944=1994904

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


Re: [OSM-talk] Should we map things that do not exist?

2020-05-25 Per discussione Mateusz Konieczny via talk



May 25, 2020, 06:37 by jacknst...@sprynet.com:

>
> Greetings.
>
>
>
>
>
> Recently, a user mapped “razed” railways inside a construction zone (link 
> below). These rails had been removed by our local mappers since they don’t 
> exist anymore. Using the latest imagery (Maxar), you can see the rails have 
> been completely removed from “Project 70”, a $1.2 billion Denver-area 
> transportation corridor construction project.
>
>
>
>
>
> I think this mapper has good intentions, but what is the point of mapping 
> something that does not exist? Doesn’t this clearly contradict the OSM Good 
> Practice wiki in regards the sections, “Verifiability”, “Map what's on the 
> ground” and “Don't map historic events and historic features”? The last 
> section states, "> Do not map objects if they do not exist currently> ."
>
>
Rails were removed - but is there embankment or something similar that makes 
clear 
that railway line was there? 

In cases of still present embankment it is a bit tricky what is border between 
"present" and "gone".

Note also that recently gone objects may be temporarily keep to prevent them 
from accidental
remapping - for example based on old memory or old aerial images.

But yes, something completely gone can and should be deleted from OpenStreetMap
(temporarily kept in way that marks it as gone if likely to be accidentally 
remapped).

>
> Should we leave (invisible) destroyed buildings in place, tag them as razed 
> and then create new buildings on top of them?
>
>
I do this to make people using outdated aerial images less confused. And delete 
them
once aerial images are updated.

I deleted object where people were either importing old objects, nonexisting 
objects unlikely
to be remapped by accident, supposedly existing old objects that were 
unverifiable.


> Should we map things that do not exist?

No, but remapping existing objects as "this is gone now" (building=yes -> 
demolished:building=yes)
is often a good idea.

But someone adding nonexisting railways, nonexisting buildings, historic 
boundaries and so on 
should stop, and such additions be reverted.

(note that ruined buildings, ruined railways are mappable, just completely gone 
are not).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Per discussione Romain MEHUT
Pour mémoire : 
https://www.mail-archive.com/talk-fr@openstreetmap.org/msg81574.html


Romain

Le 25/05/2020 à 12:36, Marc M. a écrit :

Bonjour,

Le 25.05.20 à 10:28, Yves P. a écrit :

Quel format faut-il utiliser ?
1bis, 1 bis, 1B, 1BIS, 1 BIS…

http://cadastre.openstreetmap.fr dit B,T,Q→ bis, ter, quater   A→␣A
donc "1 bis"
mais effectivement cela devrait se trouver sur le wiki qlq part.

Cordialement,
Marc

___
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: [OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Per discussione Marc M.
Bonjour,

Le 25.05.20 à 10:28, Yves P. a écrit :
> Quel format faut-il utiliser ?
> 1bis, 1 bis, 1B, 1BIS, 1 BIS…

http://cadastre.openstreetmap.fr dit B,T,Q→ bis, ter, quater   A→␣A
donc "1 bis"
mais effectivement cela devrait se trouver sur le wiki qlq part.

Cordialement,
Marc

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


Re: [Talk-es] Demarcaciones sanitarias

2020-05-25 Per discussione Jorge Sanz Sanfructuoso
Buenas.

A lo mejor se puede hacer igual que en las zonas administrativas que se
añade en la relación un admin_center. Añadir en estas zonas algo parecido
con el centro de salud principal de la demarcación sanitaria.

Un saludos.


El lun., 25 may. 2020 a las 2:43, Diego Cruz ()
escribió:

> Hola, Rafael:
>
> Muchas gracias por tu respuesta.
>
> Un compañero me ha advertido de que el único país donde estaba mapeado
> esto era el Congo, y allí utilizaban "health". Sin embargo, yo diría que
> "health" en inglés es más bien la salud de uno mismo, mientras que
> "healthcare" se refiere a la sanidad o atención sanitaria. Por eso había
> optado por esto último (además de que está el grupo de etiquetas
> "healthcare").
>
> Acabo de subir la primera zona básica de salud (rural) como ensayo piloto
> (changeset #85697721) y al hacerlo me he dado cuenta de algunos fallos en
> lo que había propuesto, como el tema de la referencia que mencionas.
> Coincido en que es una tontería inventarse "health_ref", así que había
> puesto ref:healthcare, pero si basta con "ref" a secas, por mí no hay
> problema, lo cambio. No soy muy experto en el tema de las referencias.
>
> Es decir, me parece perfecto lo que dices (*boundary=healthcare +
> healthcare_level=X*) con ref a secas, pero cambiando health por
> healthcare (aunque se esté usando ya health, yo creo que si se propone a
> nivel mundial la gente de habla inglesa no va a aceptar health, aunque todo
> es cuestión de ver qué pasa).
>
> En cuanto al etiquetado de los centros, teniendo en cuenta el conflicto
> existente entre amenity=x y healthcare=x que han mencionado algunos
> compañeros, he optado por poner las dos, y que se borre automáticamente
> después la que quede en desuso.
>
> También he visto que para los consultorios de atención primaria sería
> "doctors" y no "doctor" como había puesto.
>
> Un saludo
> Diego
>
>
> El lun., 25 may. 2020 a las 1:59, Rafael Avila Coya ()
> escribió:
>
>> Hola, Diego:
>>
>> En la República Dem. del Congo se están mapeando las zonas sanitarias del
>> país. Hace unos años atrás colaboré con Claire Halleux de la comunidad
>> local congolesa sobre el tagging para esas entidades, pues no teníamos
>> referencia en otros países.
>>
>> Por consistencia con los datos que ya hay, estaría bien seguir ese
>> esquema, y quizás luego proponerlo para la wiki global para que en otros
>> países se siga también este mismo esquema, y no que haya varios esquemas
>> diferentes para lo mismo.
>>
>> La sección en la que se explica es esta:
>> https://wiki.openstreetmap.org/wiki/Congo-Kinshasa/Zones_de_sant%C3%A9#Trouver_les_bons_tags
>>
>> Basicamente es boundary=health + health_level=X
>>
>> En cuanto a ref, podría usarse la etiqueta ref=* que ya existe en la
>> wiki, en vez de crear una health_ref.
>>
>> Saludos,
>>
>> Rafael.
>> O 24/05/20 ás 21:54, Diego Cruz escribiu:
>>
>> Hola a todos:
>>
>> En el grupo de Castilla y León hemos estado hablando sobre mapear una
>> serie de límites territoriales y por iniciativa personal he propuesto
>> empezar con los distritos sanitarios. Os dejo un esquema de mi propuesta
>> para los usuarios de Castilla y León y por si pudiese aprovecharse en otras
>> autonomías.
>>
>> El territorio podría dividirse utilizando la etiqueta
>> *boundary=healthcare_administration*, siguiendo el ejemplo de
>> religious_administration (y que podría copiarse para
>> environment_administration o agriculture_administration en otras
>> demarcaciones que existen a nivel local). Para los tres niveles de
>> organización que hay (autonomía, áreas de salud y zonas básicas de salud)
>> podría utilizarse *healthcare_level* al modo de admin_level. Es decir:
>>
>> Área de salud de León
>>
>> *name=León *
>> *boundary=healthcare_administration*
>> *healthcare_level=6* (nivel de provincia)
>>
>> Zona básica de salud de Babia
>> *name=Babia*
>> *boundary=healthcare_administration*
>> *healthcare_level=7* (nivel de comarca)
>> *healthcare_ref=170304*
>>
>> En cuanto a los centros médicos, propongo el siguiente esquema, a modo de
>> resumen de lo que probablemente ya esté mapeado:
>>
>> - *Healthcare=hospital *para los grandes hospitales que hay en cada
>> unidad de salud (capitales de provincia, básicamente), denominados
>> complejos asistenciales, hospitales universitarios, etc.
>> - *Healthcare=clinic* para los centros de salud que hay en cada núcleo
>> de una zona básica de salud, denominados oficialmente centros de salud
>> - *Healthcare=doctor* para las consultas de los pueblos pequeños
>>
>> Además, los centros que tengan puntos de atención continuada (entiendo
>> que eso es lo que son las urgencias en el lenguaje de la Junta) pueden
>> marcarse con *emergency=yes*, los centros de especialidades
>> (ambulatorios) con *healthcare=specialities* (este etiquetado no existe,
>> pero no he encontrado nada que refleje lo que son estos centros, que en
>> Castilla y León están a medio camino entre un centro de salud y un
>> hospital), y *healthcare=hospice* 

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire (osm: message 16 of 20)

2020-05-25 Per discussione Marc M.
Le 25.05.20 à 10:44, Yves P. a écrit :
>> *Fond de carte* : pouvoir basculer entre OSM et BDOrtho IGN serait
>> appréciable :)
>>
>>
>> La licence IGN accordé à OSM ne couvre pas
>> uniquement openstreetmap.org  ?
> 
> De mémoire elle est accordée pour cartographier dans OSM (il n'y a pas
> de restriction sur l'outil et/ou le nom de domaine à utiliser).

la licence n'a en effet pas de restriction d'outils pour contribuer à osm.
le proxy IGN a lui quelques tests pour éviter l'utilisation illégale.
je ne sais plus par coeur le message affiché, mais quand l'outil
aura la config, si le message s'affiche, yaka le dire pour ajouter
ce site dans la liste des sites servant à contribueer

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


Re: [Talk-at] Abzeichnen von OpenTopoMap?

2020-05-25 Per discussione Patrick Strasser-Mikhail


Am 25.05.20 um 09:18 schrieb Friedrich Volkmann:

On 25.05.20 08:43, Patrick Strasser-Mikhail wrote:

Nicht alles ist Österreich.


Hier schon. Was glaubst du, wofür das "AT" in Talk-AT steht? 



Für die österreichische Community, mit weitgehend freundlichen und 
hilfsbereiten Menschen die gerne bei allgemeinen Fragen weiter helfen 
und speziell kompetent sind für Österreich.



Auf jeden Fall gibt es zwei Mailinglisten für Lizenzfragen: 
Legal-general und legal-talk.



Danke, diese Information hat weiter geholfen.

LG Patrick/trapicki


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


Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

2020-05-25 Per discussione osm . sanspourriel

C'est moi.

J'utilise bouche dans le sens générique (poteau, borne...).

C'est gênant que tu ne vois pas qui a mis cette info.

> D'où l'utilité des photos pour voir d'autres objets ? Ça aurait du
sens avec pic4review ?
Oui, même Osmose pour ouvrir dans JOSM avec les valeurs préparées.

Ajouter un objet aussi petit sans savoir où on doit le mettre, c'est
gênant et donc j'ai masqué sur cet outil les points non rapprochables.

N. B. : voir si des gens ont déjà essayé de cartographier l'objet
pourrait être intéressant.

Au fait on clique "impossible à rapprocher" et ça atterri dans
"rapprochement compliqué".

L'outil permet maintenant de rapprocher PI CLUNY 30 et PI CLUNY 29... :-)

Le 25/05/2020 à 10:33, Nicolas Bétheuil - nbethe...@free.fr a écrit :

Sinon j'ai pleins de "Pas de bouche OSM dans les parages" kiki à fait ça ?
Je comprends pas.

Est-ce qu'en faite avec ce jeu de données on ajoute des
emergency=fire_hydrant mais en fait ça se colle à côté d'une bouche ?
Je comprends pas. Les fire_hydrant ne sont pas des bouches à incendies
justement ? Du coup faut juste les créer. Il faut chercher un poteau ?
D'où l'utilité des photos pour voir d'autres objets ? Ça aurait du
sens avec pic4review ?



Le sam. 23 mai 2020 à 21:19, Yves P. mailto:yves.prat...@gmail.com>> a écrit :

Bonsoir,


Oups effectivement quelque troue dans la raquette.

@Nicolas

Premiers essais :

http://od2osm.cleverapps.io/#/quests/2/points/PI%20CLUNY%2019
*Conflation impossible* pourquoi ?
Overpass ne trouve pas de PI dans un rayon de 60 m. Mais il n'y a
pas cette option dans la liste ;)

J'ai cliqué sur "Impossible à rapprocher" : je me retrouve dans la
quête.
Si je choisi "Rapprochement compliqué", je retrouve ce POI.

Le terme "compliqué" est mal choisi : dans ce cas le rapprochement
est impossible faute de trouver un poteau d'incendie dans OSM.

Un lien/bouton permettant de d'*ajouter cet objet dans JOSM* (ou
iD) serait le bienvenu :)
Si il n'y a rien dans OSM, j'aimerais l'ajouter ;)

*Fond de carte* : pouvoir basculer entre OSM et BDOrtho IGN serait
appréciable :)

*Libellés tronqués* :
Sur Safari et Firefox ils sont tronqués (bouton "impossible à
rapprocher", choix dans la liste déroulante)
Sur Chrome, tout est lisible :)


@Antonin et Nicolas
D'où sort *name=PI CLUNY 19* ?
Il y a une référence dans les données ouvertes : ID_SDIS.

Dans le script d'Antonin
,
je ne vois pas de "recopie" dans le tag name.
J'en déduis que Nicolas "invente" des données :D

@Nicolas est-ce possible d'afficher un extrait du fichier de
donnée de la quête ?
Et/ou des infos sur la source de données ?

*Points traités :*
Le lien sur un point traité affiche {"statusCode":404,"error":"Not
Found","message":"Not Found"}.
Un lien sur l'objet OSM serait appréciable à la place :)

En cours : modification /création
Qu'est-ce que ça doit faire ?
En cliquant sur un POI, ça relance à nouveau la requête overpass
de rapprochement.

@Nicolas
Ton outil me semble un bon complément aux outils existants (JOSM
et Osmose).
Merci, continue :)
__
Yves
___
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
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-es] Datos IET - Xunta de Galicia

2020-05-25 Per discussione Jorge Sanz Sanfructuoso
Buenas.

En el gestor estamos alejandroscf, cronoser y yo de administradores. Si
necesitas acceso para familiarizarte dime usuario y te doy permisos para
crear proyectos.

Saludos.

El dom., 24 may. 2020 a las 23:17, Santiago Crespo (<
openstreet...@flanera.net>) escribió:

> Si, se puede crear un proyecto en el gestor de tareas por cada proyecto
> de importación como las parroquias. Eso sí, antes tiene que estar
> definido cómo será el proceso en la wiki y que no haya más pegas sin
> resolver en esta lista y en imports.
>
> Creo recordar que tendrás que pedir a Javier Sánchez que dé permisos a
> tu usuario de OSM para que puedas crear proyectos en el gestor, esto
> podrías hacerlo ya. Así podrías crear un proyecto de pruebas (no
> público) para que te familiarices con el gestor como administrador de
> proyectos.
>
> On 5/24/20 10:46 PM, Miguel Branco wrote:
> > Gracias por las aportaciones, Santiago!
> >
> > Si, me centré en crear una página donde se describa objetivo por
> > conjunto de datos. Pero efectivamente, alguno de ellos llevará tiempo y,
> > también por comodidad, debería tener su propia web. Intentaré irlos
> creando.
> >
> > El gestor de tareas nos vendría fantástico para datos como los de añadir
> > parroquias. Se podría abrir un proyecto allí?
> >
> > O dom., 24 de maio de 2020 ás 21:55,  > > escribiu:
> >
> > Message: 2
> > Date: Sun, 24 May 2020 17:25:07 +0200
> > From: Santiago Crespo  > >
> > To: talk-es@openstreetmap.org 
> > Subject: Re: [Talk-es] Datos IET - Xunta de Galicia
> > Message-ID: <8cad392d-ecf4-303e-1c78-2f3205140...@flanera.net
> > >
> > Content-Type: text/plain; charset=utf-8
> >
> > Ola Miguel,
> >
> > Enhorabuena por conseguir la autorización y carta de exención
> firmadas,
> > buen trabajo. Las he subido al wiki con las categorías
> > "ES:Autorizaciones para usar fuentes de datos de España",
> "Documents" y
> > "ES:Galicia". He cambiado los enlaces para que apunten a los
> documentos
> > en el wiki, cambiando un poco del texto que acompaña a los enlaces.
> >
> > Creo que cada proyecto de importación tendría que tener su propia
> > página, en lugar de ser secciones en una página enorme. Así será más
> > facil que la comunidad revise cada proyecto, de uno en uno. Si además
> > están en inglés, será más fácil para imports pero esto ya es
> opcional.
> > Recuerdo que en una de las primeras propuestas del catastro nos
> pusieron
> > pegas en la lista de imports por intentar organizar una importación
> de
> > varios tipos de elementos a la vez.
> >
> > Quizá podrías mantener la página de IET_Import como un índice que
> enlace
> > con las páginas individuales para cada proyecto.
> >
> > Sobre la página con los estados de importación, si usamos el gestor
> de
> > tareas creo que no haría falta ir actualizando la wiki para apuntar
> lo
> > que está hecho o no.
> >
> > Por ahora no he leído detalladamente las propuestas concretas ni he
> > visto los datos originales.
> >
> > Saludos!
> > Santiago Crespo
> >
> >
> > ___
> > Talk-es mailing list
> > Talk-es@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-es
> >
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>


-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://jorgesanz.es/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es


Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

2020-05-25 Per discussione Colin Smale
On 2020-05-25 10:27, Florian Lohoff wrote:

> A small and very vocal part of the German community proposes to tag
> EVERY driveway - no matter if it has a gate or sign with access=private.
> Somebody slipped stuff into the German access=private page which i
> removed a while back as it had no consensus. Still some continue with
> this practice and for me they break the delivery use-case and a lot of
> other stuff (You cant to blind navigation to the front door as private
> has to be honored)
> 
> You cant tell whether this access=private is okay to break, and the
> other not.

"private" is not the same as "no". It simply means that the owner has
the right to decide who to admit, and the default is "no access" unless
you have explicit or implicit permission from the owner. 

With respect to private driveways, they are simply private. The owner
will tolerate friends and neighbours, postmen, delivery drivers etc
coming to the door - you could say they have implicit permission. A
random person however has no implicit permission and must keep out. 

In Germany it sounds like it is the same as it is here in the
Netherlands. If you don't put up a sign saying "keep out" or equivalent,
no actual offence is committed by passing the sign onto your land.
However you, as the land owner, have the sole right to erect such a sign
at your discretion and to make the rules as you see fit. 

There is also the category "access=permissive" which is in the middle.
You have no statutory right to access the land, however the owner has
clearly decided to allow the public access (i.e. everybody has implicit
permission). The owner can (in theory at least) rescind that implied
easement at any time or otherwise restrict access.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire (osm: message 16 of 20)

2020-05-25 Per discussione Yves P.
> Fond de carte : pouvoir basculer entre OSM et BDOrtho IGN serait appréciable 
> :)
> 
> La licence IGN accordé à OSM ne couvre pas uniquement openstreetmap.org 
>  ?

De mémoire elle est accordée pour cartographier dans OSM (il n'y a pas de 
restriction sur l'outil et/ou le nom de domaine à utiliser).

__
Yves

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


Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire (osm: message 16 of 20)

2020-05-25 Per discussione Nicolas Bétheuil
Sinon j'ai pleins de "Pas de bouche OSM dans les parages" kiki à fait ça ?
Je comprends pas.

Est-ce qu'en faite avec ce jeu de données on ajoute des
emergency=fire_hydrant mais en fait ça se colle à côté d'une bouche ? Je
comprends pas. Les fire_hydrant ne sont pas des bouches à incendies
justement ? Du coup faut juste les créer. Il faut chercher un poteau ? D'où
l'utilité des photos pour voir d'autres objets ? Ça aurait du sens avec
pic4review ?



Le sam. 23 mai 2020 à 21:19, Yves P.  a écrit :

> Bonsoir,
>
> Oups effectivement quelque troue dans la raquette.
>
> @Nicolas
>
> Premiers essais :
>
> http://od2osm.cleverapps.io/#/quests/2/points/PI%20CLUNY%2019
> *Conflation impossible* pourquoi ?
> Overpass ne trouve pas de PI dans un rayon de 60 m. Mais il n'y a pas
> cette option dans la liste ;)
>
> J'ai cliqué sur "Impossible à rapprocher" : je me retrouve dans la quête.
> Si je choisi "Rapprochement compliqué", je retrouve ce POI.
>
> Le terme "compliqué" est mal choisi : dans ce cas le rapprochement est
> impossible faute de trouver un poteau d'incendie dans OSM.
>
> Un lien/bouton permettant de d'*ajouter cet objet dans JOSM* (ou iD)
> serait le bienvenu :)
> Si il n'y a rien dans OSM, j'aimerais l'ajouter ;)
>
> *Fond de carte* : pouvoir basculer entre OSM et BDOrtho IGN serait
> appréciable :)
>
> *Libellés tronqués* :
> Sur Safari et Firefox ils sont tronqués (bouton "impossible à rapprocher",
> choix dans la liste déroulante)
> Sur Chrome, tout est lisible :)
>
>
> @Antonin et Nicolas
> D'où sort *name=PI CLUNY 19* ?
> Il y a une référence dans les données ouvertes : ID_SDIS.
>
> Dans le script d'Antonin
> , je ne
> vois pas de "recopie" dans le tag name.
> J'en déduis que Nicolas "invente" des données :D
>
> @Nicolas est-ce possible d'afficher un extrait du fichier de donnée de la
> quête ?
> Et/ou des infos sur la source de données ?
>
> *Points traités :*
> Le lien sur un point traité affiche {"statusCode":404,"error":"Not
> Found","message":"Not Found"}.
> Un lien sur l'objet OSM serait appréciable à la place :)
>
> En cours : modification /création
> Qu'est-ce que ça doit faire ?
> En cliquant sur un POI, ça relance à nouveau la requête overpass de
> rapprochement.
>
> @Nicolas
> Ton outil me semble un bon complément aux outils existants (JOSM et
> Osmose).
> Merci, continue :)
> __
> Yves
> ___
> 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


[OSM-talk-fr] Normalisation des bis, ter…

2020-05-25 Per discussione Yves P.
Bonjour,

Je rajoute un "13 bis " dans 
addr:housenumber.

Quel format faut-il utiliser ?
1bis, 1 bis, 1B, 1BIS, 1 BIS…

Je ne vois rien dans le wiki .

D'après TagInfo, c'est "xx bis" qui gagne.

Bis 5187

BIS 37979   espace  84717
bis 107096  sans espace 65545
total   150262  total   150262

Qu'est-ce que préconise adresse.gouv.fr / BAN / BANO ?

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


Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

2020-05-25 Per discussione Florian Lohoff

Hi Mateusz,

On Mon, May 25, 2020 at 01:11:04AM +0200, Mateusz Konieczny via talk wrote:
> > At least thats very different in Germany. There is no such thing as
> > "Stand your ground" in the US legalese. As long as you dont show
> > clear intend of "out of bounds" e.g. fences, gates or signage
> > its not a federal offense to walk on private property. You may
> > still be sent away, ignoring THAT is a federal offense, but until
> > then there its no legal offense to step on private property.
> >
> So it is about a road that is without "no entry" signs, not marked 
> as privately owned, without gate/chain etc?
> 
> Tagging it as access=private seems wrong.

Correct - Thats my point.

> > So we tag stuff people are assumed to ignore? We should fix tagging
> > to make it distinguishable.
> >
> Depends on your usecase - for routing you may want to inrerpret
> access=private on final approach differently.
> 
> It may be valuable info for example for a renderer.
> 
> But what you want to distinguish here?
> 
> "owner has locked gate but orders pizza often, will open gate for delivery" 
> from
> "owner has locked gate and never orders deliveries"?
> 
> I am probably missing something.

Its not MY usecase - but we should take care not to mix up data people
are using TODAY - And Amazon Logistics is fixing stuff like that already
today as we broke it, or made it impossible to distinguish it.

A small and very vocal part of the German community proposes to tag
EVERY driveway - no matter if it has a gate or sign with access=private.
Somebody slipped stuff into the German access=private page which i
removed a while back as it had no consensus. Still some continue with
this practice and for me they break the delivery use-case and a lot of
other stuff (You cant to blind navigation to the front door as private
has to be honored)

You cant tell whether this access=private is okay to break, and the
other not.

> > Its indistinguishable - Thats the problem. A private on a driveway
> > is definitly something which is not verifyable in most cases
> >
> Why it is not verifiable?
> 
> (it may be a cultural difference, in Poland driveway with restricted 
> access will have a gate or at least a sign, it is not a driveway with 
> restricted
> access otherwise)

Ah - Thats a different issue. In Germany the small group proposes to tag
EVERY driveway with access=private - mixing it up with private property.

So - when there is no sign, no chain, no gate - How do you verify the
intention of the owner that it is "out of bounds"? You cant. 
And for that breaks a pretty important rule of OSM that it must be
verifyable.


> > For me a service is by itself not for the general public as the service
> > article already states. Tagging it with driveway does make it even less
> > public. It will be not used as through road anyway.
> >
> I may be a bit unusual here but it is often not true for cyclists and hikers.
> They often use serice roads (even driveway segments) that are not private, 
> that is why 
> distinguishing between driveway accessible to general public and
> restricted one is important for me.
> 
> For example 
> https://www.openstreetmap.org/way/240494343#map=19/50.06452/19.92326
> (driveway into an university area, signed as living_street is a part of 
> alternative route for
> cyclists allowing to skip dual carriageway with heavy trafffic)
> 
> https://www.openstreetmap.org/way/174699639#map=19/49.26939/19.98083
> service road (correctly tagged) carrying hiking trails and almost
> certainly incorrectly tagged as inaccessible for pedestrians
> ( https://www.openstreetmap.org/note/2205168 ).
> 
> https://www.openstreetmap.org/way/714080089#map=19/49.28399/20.00194
> correctly tagged driveway, serving as public wheelchair accessible path
> toward major tourism attraction (correctly tagged as without access
> restrictions
> https://pl.wikipedia.org/wiki/Kaplica_Naj%C5%9Bwi%C4%99tszego_Serca_Jezusa_w_Jaszczur%C3%B3wce#/media/Plik:Kaplica_Jaszczurowka.jpg)

A driveway is not something which is per se "out of bounds" - At least
OSRM treats it a lot like "destination" e.g. increases the cost of
routing. This was my example - a service/driveway in OSRM acts a lot
like a destination, whereas the same with access=private is
inaccessible.

> > So there is a difference between a driveway with and without any signs, 
> > gates or
> > fences. If not globally than at least for Germany.
>
> Yes, also in Poland there are driveways without any access restrictions
> and ones that are restricted to private access and some with more exotic ones.

Right - thats my point. As soon as there is some visible intent of the
owner that the driveway is out of bounds - like a sign, chain, gate,
fence etc i am happy with taking this intent into OSM by using e.g.
access=private. Without such intent there is no need to put access
restrictions in place. Thats my case with "On the ground" and "Not every
driveway needs an access=private" - We want to have a 

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire (osm: message 16 of 20)

2020-05-25 Per discussione Nicolas Bétheuil
Beaucoup de choses, vais tâcher de répondre dans le texte

Le sam. 23 mai 2020 à 21:19, Yves P.  a écrit :

> Bonsoir,
>
> Oups effectivement quelque troue dans la raquette.
>
> @Nicolas
>
> Premiers essais :
>
> http://od2osm.cleverapps.io/#/quests/2/points/PI%20CLUNY%2019
> *Conflation impossible* pourquoi ?
> Overpass ne trouve pas de PI dans un rayon de 60 m. Mais il n'y a pas
> cette option dans la liste ;)
>

Il n'y a pas de fire_hydrant dans les 20m, 40m, +20m... du coup il y a le
bouton créer qui s'active quand la requête overpass est revenu, pas besoin
d'ouvrir un autre outil.
Je note quand même, même si vous faisiez remarquer qu'utiliser plusieurs
outils allaient complexifier l'histoire
https://github.com/wadouk/od2osm/issues/16

Même si on peut déjà dire qu'il n'y a rien n'a changer et du coup marquer
le point comme OK


>
> J'ai cliqué sur "Impossible à rapprocher" : je me retrouve dans la quête.
> Si je choisi "Rapprochement compliqué", je retrouve ce POI.
>

En cliquant sur Impossible à rapprocher une sous partie s'affiche pour
expliquer le pourquoi. En validant cette explication, il change de statut
pour soit repasser dessus plus tard, soit le faire autrement.


> Le terme "compliqué" est mal choisi : dans ce cas le rapprochement est
> impossible faute de trouver un poteau d'incendie dans OSM.
>
> Un lien/bouton permettant de d'*ajouter cet objet dans JOSM* (ou iD)
> serait le bienvenu :)
> Si il n'y a rien dans OSM, j'aimerais l'ajouter ;)
>

D'où le bouton créer, mais je suspecte que quelque chose se passe mal et
que du coup vous ne voyez pas le bouton...


>
> *Fond de carte* : pouvoir basculer entre OSM et BDOrtho IGN serait
> appréciable :)
>

La licence IGN accordé à OSM ne couvre pas uniquement openstreetmap.org ?


>
> *Libellés tronqués* :
> Sur Safari et Firefox ils sont tronqués (bouton "impossible à rapprocher",
> choix dans la liste déroulante)
> Sur Chrome, tout est lisible :)
>
>
> @Antonin et Nicolas
> D'où sort *name=PI CLUNY 19* ?
> Il y a une référence dans les données ouvertes : ID_SDIS.
>
> Dans le script d'Antonin
> , je ne
> vois pas de "recopie" dans le tag name.
> J'en déduis que Nicolas "invente" des données :D
>

Pourtant en base je vois bien des name ...


> @Nicolas est-ce possible d'afficher un extrait du fichier de donnée de la
> quête ?
> Et/ou des infos sur la source de données ?
>

Rappeler l'url d'origine, la donnée d'origine je ne l'ai pas mais un champs
commentaire en markdown pour pouvoir rappeler un peu de contexte, je note
l'idée
https://github.com/wadouk/od2osm/issues/17


>
> *Points traités :*
> Le lien sur un point traité affiche {"statusCode":404,"error":"Not
> Found","message":"Not Found"}.
>

D'où ça vient ce 404 ?

Un lien sur l'objet OSM serait appréciable à la place :)
>
> En cours : modification /création
> Qu'est-ce que ça doit faire ?
> En cliquant sur un POI, ça relance à nouveau la requête overpass de
> rapprochement.
>

Une "forme de réservation" pour pas faire échouer un changeset d'un voisin
qui a commencé à bosser dessus et qui a acquitter que c'était une création
ou une modification mais pas encore validé le changeset.


>
> @Nicolas
> Ton outil me semble un bon complément aux outils existants (JOSM et
> Osmose).
> Merci, continue :)
>

Merci

__
> Yves
> ___
> 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: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

2020-05-25 Per discussione Lester Caine

On 24/05/2020 23:45, Mateusz Konieczny via talk wrote:

There are also many roads signed as "No HGVs except for access." It
is tempting to tag them as "hgv=destination" but that doesn't cover
the case where you are allowed to follow that route for many miles
and make several turnoffs IF you "need access". The current
definition of "access=destination" doesn't allow routers to
distinguish between truly "first/last segment only" and "its fine if
you are going to/from this general area".

AFAIK this awaits solution, at least I am not aware about even a tag 
proposal.


A delivery driver following a drop list may have a drop on that road, 
and then go on to their next drop out of the other end of the road. In 
fact it may be that the road is impractical for the vehicle to turn 
around. The 'legal' restriction is to prevent lorries using it as a 
short cut through a residential or similar area and physically it is 
perfectly practical for the biggest legal vehicle. The router can simple 
avoid that road if there is no stop on it, but the tagging should 
ADDITIONALLY indicate if it is physically possible to get the vehicle to 
the destination so obstructions such as tight corner, overhanging 
buildings, weight restrictions and the like will prevent some of the 
examples of lorries blindly following their sat nav without their brains 
in gear? It is the routers problem to pick the best route, which may be 
to approach the destination from the other end and perhaps even indicate 
'back up to destination' ... now that WOULD be an intelligent router ... 
but if there is no information on which to base that decision even the 
driver has to guess.


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk

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


Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

2020-05-25 Per discussione Nicolas Bétheuil
c'est prévu
https://github.com/wadouk/od2osm/issues/15

PS : merci, super premier cas grandeur nature.

Le sam. 23 mai 2020 à 17:51, Antonin Delpeuch (lists) <
li...@antonin.delpeuch.eu> a écrit :

> Correction: la conflation marche malgré l'absence de noms (chouette !)
> sauf dans certains cas (peut-être à cause de limites de nombre de
> requêtes ?)
>
> Autre détail: quand on ajoute un POI au changeset, il faut un certain
> nombre de clics pour revenir à la liste des points à traiter dans la
> quête. Ça serait pratique d'y revenir directement, ou même mieux, de
> passer à un autre point à traiter.
>
> En tout cas super outil !
>
> Antonin
>
> ___
> 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-GB] hgv=discouraged

2020-05-25 Per discussione Ed Loach
I used motor_vehicle=unsuitable here https://www.openstreetmap.org/way/26551700 
for want of a better tag. I wouldn't ever drive it, as having walked it and 
seen all the scrapes in the road surface where cars bottom out on the sharp 
transition from the steep slopes up to the bridge to the horizontal bit over 
the railway I wouldn't want to risk the damage to my car. Many people do though 
- presumably in company cars.

Ed

From: Philip Barnes 
Sent: Monday, May 25, 2020 1:29:00 AM
To: talk-gb@openstreetmap.org 
Subject: Re: [Talk-GB] hgv=discouraged

Hi Mateusz
You would need to venture deep into the rural UK to start finding these signs, 
they are quite common around here.
An example here
https://www.mapillary.com/map/im/Hys6QlJfrRC9fNHsPzeTTQ

This one is just narrow, with few ad-hoc passing places, places to squeeze to 
allow another car to pass but certainly not a hgv. Meet one and hopefully you 
are good at reversing.

One thing that was not mentioned on the international list was there is also 
Unsuitable for Motor Vehicles.

An example here
https://www.mapillary.com/map/im/7DD5trbqVEil3AKJCJeJDg

In practical terms the question is what does this mean.
Well its not a good idea for a router to use these roads blindly, so although 
this example I have driven through it many times.
The practical problems are that it is a narrow single track road, no space to 
turn and after a heavy rain it likely to be under deep water which can flood 
and destroy the engine of a modern car.
Would I drive through there tomorrow, well yes. I know it has been dry for the 
last week.

Another here https://www.mapillary.com/map/im/y3zTGNAT7MgGtxoaGXPUvQ
Well its officially an unclassified road, not a green lane or county road, many 
practical roads have this category.

It deteriorates into a very muddy, deeply rutted track. I have walked it, but 
no way would I attempt to drive the full length of it. Premises need to to 
approched from the right end.


Discouraged does seem to be a reasonable tag, effectivly =destination but a hgv 
driver in particular does need to know which end to approch from.

Phil (trigpoint)



On Mon, 2020-05-25 at 01:31 +0200, Mateusz Konieczny via Talk-GB wrote:
I created
https://wiki.openstreetmap.org/wiki/Tag:hgv%3Ddiscouraged
based on https://wiki.openstreetmap.org/wiki/Key:access content
and what I found on internet.

Triggered by post on an international mailing list by someone who was unaware
that we have a way to tag "Unsuitable for Heavy Goods Vehicles" signs.

I never was in UK, but content at https://wiki.openstreetmap.org/wiki/Key:access
about "discouraged" value seemed to be a good idea.

Review is welcomed - is it matching reality and how OSM community maps such 
objects?

This new page should be found by
https://wiki.openstreetmap.org/w/index.php?search=%22Unsuitable+for+Heavy+Goods+Vehicles%22=Special%3ASearch=Go
https://wiki.openstreetmap.org/w/index.php?search=Unsuitable+for+HGV=Special%3ASearch=default=1
searches

(and that was primary reason for creating it).


___

Talk-GB mailing list



Talk-GB@openstreetmap.org




https://lists.openstreetmap.org/listinfo/talk-gb

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


Re: [Talk-de] oneway = no

2020-05-25 Per discussione Florian Lohoff
Hola Markus,

On Mon, May 25, 2020 at 08:53:28AM +0200, Markus wrote:
> Hallo Florian,
> 
> >> 3 Zustände:
> >> - ja
> >> - nein
> >> - weiss nicht
> >>
> >> Letzterer muss noch geprüft werden
> >> (die anderen Beiden sollen regelmässig auf Änderung kontrolliert werden)
> >
> > Also nicht das ich nicht gerne label an Objekte hängen würde die ich
> > gerne rechecken würde
> 
> Es geht nicht um eine private ToDo-Liste.
> Sondern um öffentliche Qualitätsmerkmale der Daten.

Naja - Aber alles mit "weiss nicht" erstmal durchtaggen um das nach und
nach abzuarbeiten? Ist für mich eine "Private ToDo Liste"

Denn am Ende erhebt ja niemand den Anspruch das OSM vollständig
ist, ausser vielleicht der Mapper vor Ort, und das ja auch nur für
Teilaspekte.

> Angenommen, man will möglichst valide Daten, möglichst zeitnah,
> dann kommt man um eine Erfassung der Validität nicht herum.

Validität steht ja nochmal auf einem vollständig anderem Blatt.
Ob es etwas existiert oder nicht oder ob der Zustand unbekannt ist ist
ja Vollständigkeit nicht Validität. Bei Validität müssen wir uns ja auf
den Mapper verlassen das der Sorgfältig einträgt. Und das es eine
scheinbar große Fraktion gibt die gerne nach Gefühl mapped sieht man ja
gerade im Access thread im Forum.

> Beispiel:
> 
> Viele schreiben "highway=track" an eine Linie, die sie aus dem Luftbild
> oder aus Erinnerung vor Ort gemappt haben (weil sie nicht oder nicht
> mehr genau wissen, wie das genau war, aber Lage und Form kennen).
> Für den Kenner ist dadurch ersichtlich, dass noch etwas fehlt und
> verbessern das wenn sie mal vor Ort sind.
> (Anfänger denken, dass "track" etwas Genaues bezeichnet, sie aber nicht
> genau wissen was).

Naja - So funktioniert OSM - Iterativ verfeinern wir Daten. Ich bin mit
dem Zeugs was ich eintrage oft nach 10 Jahren noch nicht zufrieden.
Nicht weil es unvollständig ist (Was es immer ist) sondern weil es
meinen Ansprüchen nach Eleganz und Simplizität nicht entspricht. 

Also habe ich einen eigenen TaskManager laufen und gehe alle 2-3 Jahre die
ganzen Gemeinden durch für die ich mich interessiere. Dauert dann halt
6 Monate sich nochmal alles anzusehen. Und es gibt immer was zu
korrigieren. Nochmal zu durchdenken. Auch wenn sich die Realität nicht
geändert hat so hat sich mein Anspruch an "Schöne Daten" geändert.
Landuses werden verkleinert, anders geschnitten, Multipolygone
aufgelöst.

Das hat aber nichts damit zu tun das ich erstmal an alle Wege ein
"lit=unknown" hänge und das nach und nach abarbeite.

> Bei eindeutigen Merkmalen wie "oneway=yes" ist es klar, da steht ein
> Schild. Aber wenn ich mich nur erinnere, dass dort "irgendwo" ein Schild
> stand, vielleicht in einer anderen oder abzweigenden Strasse, wie kann
> ich das dann angeben, damit es Dritte unterscheiden können von "da ist
> (vielleicht) was" oder da ist "sicher nichts"?

Ich habe 2014-2015 einen Grossteil der Gemeinden stumpf komplett via
Mapillary abgelichtet, und bin gerade in einem rerun. Und ja - Ich habe
eine neue Einbahnstraße entdeckt. Wie lange die existiert - keine
Ahnung. Warum hat die kein anderer Mapper entdeckt? Keine Ahnung.  Hätte
mir irgendein tag geholfen. Nein - 2014 hätte ich ein oneway=no dran
gehängt. Hätte ich mich heute stumpf daran orientiert wäre das heute
noch nicht eingetragen. Also ein zu großer Verlass auf Tags ist auch
sehr trügerisch - Womit wir wieder bei der obigen Validität sind.
Wenn ich mich drauf verlasse was andere eintrage, und das nicht kritisch
hinterfrage, ist die Karte innerhalb weniger Jahre unbrauchbar. Es
ändert sich ständig was und in Großteilen Deutschlands sind wir seit
Jahren im Maintenance Modus. Wie aber bekommen wir mit DAS sich was
ändert. Und da hat keiner eine Antwort drauf.

Ich Monitore für Adressen die wöchentlichen opendata exporte meines
Kreises und kriege Diffs zugeschickt wenn die neue Adressen zuteilen.
Und sowas brauchen wir viel mehr. Ich hätte gerne eine Kopie aller 
Verkehrsrechtlichen Anordnungen - Dann würde man sofort die
Geschwindigkeitsänderungen, Einbahnstraßen und Co mitbekommen. Hab ich
bloss noch nicht raus bekommen wie ich die bekomme.

> Oder bei (strassen)"name=*" bei eindeutiger Ortsstrasse, deren Name ich
> nicht kenne? oder bei der es gar keine Namen gibt?
> 
> Je älter OSM wird, desto problematischer werden Konflikte zwischen
> "Bekannt" und "Unbekannt".
> 
> Und ja, wenn man das verbessern will:
> - brauchen wir definierte Meta-tags
> - wird die DB grösser

Aber dafür müssten wir ja definieren welche use-cases wir abbilden
wollen. Und Vollständigkeit ist ein ganz schlechter Use-Case weil er
die Pflege bzw Änderung im Bestand verschleiert.

Und ich bin nach wie vor nicht dafür das in die DB zu packen. 

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org

Re: [OSM-talk-fr] Import de points d'eau incendie en Saône-et-Loire

2020-05-25 Per discussione Nicolas Bétheuil
Pour virer les name déjà dans OSM, OSMOSE est ton ami, il doit te dire
qu'il y a plein de boulettes ;-P
Je regarde pour corriger ça rapidement, après Antonin pourra refaire son
jeu de données sans ces tags name

Le sam. 23 mai 2020 à 22:07,  a écrit :

> Pour ma part je consolide les données existantes dans OSM avec
> http://od2osm.cleverapps.io/.
>
> N. B. : Nicolas, ce serait bien de virer "name", les PEI (j'ai appris
> une abréviation) n'ayant pas de nom.
>
> Jean-Yvon
>
> Le 23/05/2020 à 18:09, Marc M. - marc_marc_...@hotmail.com a écrit :
> > Bonjour,
> >
> > ja'i du raté l'info de ce que tu fais pour pouvoir intégrer
> > ces bornes comparé à un import ?
> >
> > Le 23.05.20 à 17:06, Antonin Delpeuch (lists) a écrit :
> >> La possibilité d'ajouter les éléments manquants facilement depuis
> >> l'outil est un vrai plus - je ne vois pas
> >> comment faire ça depuis Osmose
> > exemple :
> >
> https://osmose.openstreetmap.fr/fr/map/#source=412054=8360=4=17=50.556896=2.899575=3==
> >
> > clic sur "fix-josm" te l'ajoute en un clic dans josm
> >
> > il y en a 1 en attente d'intégration en France :)
> >
> > Cordialement,
> > Marc
> >
> > ___
> > 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Voirie en aire piétonne ?

2020-05-25 Per discussione Florimond Berthoux
Faut tester aussi le access tag, genre :
motor_vehicle=private|destination|delivery
voir https://wiki.openstreetmap.org/wiki/Key:access
Peut-être qu'il faudra aussi inclure les autres type de highway (service ?
residential ?).

C'est un peu ce que l'on fait sur CyclOSM pour afficher les rues sans
trafic motorisé en vert clair, comme ici
https://www.cyclosm.org/#map=18/48.86724/2.26056/cyclosm


Le lun. 25 mai 2020 à 01:14, Shohreh  a écrit :

> Bonjour,
>
> Cette requête remonte beaucoup plus que ce que je cherchais, à savoir les
> rues qui sont aujourd'hui piétonnes, c.a.d. totalement interdites aux
> voitures, ou uniquement autorisées aux résidants via des bornes
> rétractables
> :
>
> ===
> [out:json][timeout:25];
>
> //Ville 123
> rel(123);
> map_to_area -> .searchArea;
>
> (
>   way[highway=pedestrian](area.searchArea);
> );
>
> out body;
> >;
> out skel qt;
> ===
>
> Y a-t-il un moyen de réduire les données ?
>
> Merci.
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


[OSM-talk-fr] Aménagements cyclables de déconfinement - outil carto de la FUB

2020-05-25 Per discussione Laurence P

Bonjour,

pour information, cf le dernier point de la lettre de diffusion 
ci-dessous : un outil cartographique a été créé par la FUB (Fédération 
des Usagers de la Bicyclette) et de Vélo et territoires. Note pour la 
liste Association OSMFR, c'est en lien avec l'entretien qu'avait eu 
Vincent et qu'il avait évoqué dans un email.


https://www.velo-territoires.org/actualite/2020/05/20/cartographier-amenagements-cyclables-de-transition/

Par ailleurs sachez que la vidéo du 1er webinaire que nous avons 
organisé avec Charles Millet OSM et le vélo a passé la barre des 300 
vues ! https://peertube.openstreetmap.fr/ (là tout de suite il y a une 
erreur 502)


À bientôt,

Laurence



 Message transféré 
Sujet : 	[voiriepourtous] Les Infos UVT - Aménagements cyclables de 
déconfinement

Date :  Mon, 25 May 2020 09:30:11 +0200
De : 	RENNESSON Catia (Chargée de mission) - CEREMA/DTecTV/VOI 

Répondre à : 	RENNESSON Catia (Chargée de mission) - CEREMA/DTecTV/VOI 


Organisation :  CEREMA/DTecTV/VOI
Pour : 	Diffusion d'informations relatives au programme "une voirie pour 
tous" 






Bonjour à tous,
*
**Vélo et déconfinement* : des premiers retours terrain sont disponibles 
et ainsi que différents outils de suivi.*


**WEBINAIRE du Cerema *sur les aménagements cyclables de déconfinement - 
19 mai 2020 : *le REPLAY est disponible !

*
Un mois après un premier webinaire et après avoir mis en ligne son guide 
express « Aménagements cyclables provisoires : tester pour aménager 
durablement », le Cerema a réuni de nouveau 500 acteurs de l’aménagement 
autour de cette thématique d'actualité.
Introduit par Élisabeth Borne, Ministre de la Transition écologique et 
Solidaire qui a réaffirmé l'engagement de l’État sur cette dynamique 
accélératrice des politiques cyclables, cet événement était axé sur les 
premiers retours de terrain.


Accéder au replay :*ICI 
 
*




*Un**OUTIL D’ÉCHANGE entre collectivités *dédié aux aménagements 
cyclables de transition


Pour répondre à un besoin fort de retours d'expériences et d'échanges 
sur la réalisation des aménagements cyclables de transition, l'*ADEME*, 
le *Club des villes et territoires cyclables*, *Vélo & Territoires* et 
la *Fabrique des mobilités***ont créé un outil d'échange technique à 
destination des collectivités territoriales.


Abonnement :***ICI *



*FRÉQUENTATION vélo *et déconfinement**

*Vélo & Territoires*, en lien avec *le ministère de la Transition 
écologique et solidaire*, édite un bulletin de suivi de la fréquentation 
cyclable post-confinement (publié tous les quinze jours).


En savoir plus *: **ICI *



*CARTOGRAPHIER* les aménagements cyclables de transition

Dans le contexte actuel qui voit les aménagements cyclables de 
transition émerger, l’inventaire et le référencement cartographique et 
géomatique précis à l’échelle nationale deviennent nécessaires.


Pour répondre à ce besoin, la *FUB*, *Vélo & Territoires* et le *Cerema 
*(en lien avec les partenaires mobilisés pour faciliter la mise en œuvre 
d’aménagements cyclables de transition) ont réfléchi à la meilleure 
manière de mutualiser les données géomatiques et cartographiques 
relatives aux aménagements cyclables de transition.


Résultat : *"Coupe de pouce carto", *une adaptation de l’outil 
cartographique de la Fédération française des Usagers de la Bicyclette 
(FUB),


Plus d'infos :***ICI *


---

Je vous remercie de diffuser largement cette information auprès des 
personnes intéressées de vos services.


Bien cordialement,

Catia Rennesson


/NB : Si vous ne souhaitez plus recevoir les informations Une voirie 
pour Tous, cliquez sur le lien suivant : //désabonnement/



---
*Catia RENNESSON*
*Mission "Voirie et Espace public" pour une ville durable
*Département Voirie, Espace public*
* Tél : 04 72 74 58 32 - mél : catia.rennes...@cerema.fr
Logo Cerema : centre d'études et d'expertise sur les risques, 
l'environnement, la mobilité et l'aménagement
*Centr**e d'ét**udes et d'expertise sur les risques, l'environnement, la 
mobilité et l'aménagement - www.cerema.fr*/
/Direction technique Territoires et ville - 2 rue Antoine Charial - 
69426 LYON cedex 03- Tél.  +33 (0)4 72 74 58 00
Siège social : Cité des mobilités - 25 avenue François Mitterrand 69674 
BRON cedex - Tél. +33 (0)4 72 14 30 30
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-at] Abzeichnen von OpenTopoMap?

2020-05-25 Per discussione Markus Straub
Hallo Patrick,
lass dich vom unfreundlichen Ton von Friedrich nicht abschrecken, ich finde
du hast die Frage klar formuliert und es macht durchaus Sinn hier zu fragen
als in einem Land wo es womöglich gar keine Community gibt. Leider fällt
mir Friedrich öfters negativ mit toxischen Kommentaren auf :/
LG, Markus / evod

On Mon, May 25, 2020 at 9:27 AM Friedrich Volkmann  wrote:

> On 25.05.20 08:43, Patrick Strasser-Mikhail wrote:
> > Nicht alles ist Österreich.
>
> Hier schon. Was glaubst du, wofür das "AT" in Talk-AT steht? Und warum es
> für OSM zig verschiedene Mailinglisten gibt? Für das Land, in dem du
> mappst,
> gibt es wahrscheinlich auch eine. Auf jeden Fall gibt es zwei
> Mailinglisten
> für Lizenzfragen: Legal-general und legal-talk. Dort kommst du an die
> Leute,
> die sich mit Lizenzfragen auskennen.
>
> Wenn du die Frage gleich dort gestellt hättest statt hier, hättest du dir
> viel Zeit erspart und mir auch.
>
> Wenn du eine Frage zu Katzennahrung hast, fragst du ja auch nicht in einem
> Hundeforum nach, oder?
>
> --
> 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: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access

2020-05-25 Per discussione Frederik Ramm
Hi,

On 5/25/20 00:36, Arne Johannessen wrote:
> The default motor_vehicle=* of Norwegian forest roads [1] by law [2] depends 
> on physical criteria such as tracktype=*, surface=*, smoothness=*, width=*. 
> The law makes this a judgement call in each and every case. [3]

Same with cycling in forests in some parts of Germany, I think that
legally it automatically becomes bicycle=no if width<2m but there's
often discussions about just how much of the way needs to be <2m to make
it off limits for cyclists.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Talk-at] Abzeichnen von OpenTopoMap?

2020-05-25 Per discussione Friedrich Volkmann

On 25.05.20 08:43, Patrick Strasser-Mikhail wrote:

Nicht alles ist Österreich.


Hier schon. Was glaubst du, wofür das "AT" in Talk-AT steht? Und warum es 
für OSM zig verschiedene Mailinglisten gibt? Für das Land, in dem du mappst, 
gibt es wahrscheinlich auch eine. Auf jeden Fall gibt es zwei Mailinglisten 
für Lizenzfragen: Legal-general und legal-talk. Dort kommst du an die Leute, 
die sich mit Lizenzfragen auskennen.


Wenn du die Frage gleich dort gestellt hättest statt hier, hättest du dir 
viel Zeit erspart und mir auch.


Wenn du eine Frage zu Katzennahrung hast, fragst du ja auch nicht in einem 
Hundeforum nach, oder?


--
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: [OSM-talk-fr] Voirie en aire piétonne ?

2020-05-25 Per discussione Marc M.
Bonjour,

Le 25.05.20 à 01:14, Shohreh a écrit :
> Cette requête remonte beaucoup plus que ce que je cherchais, à savoir 
> les rues qui sont aujourd'hui piétonnes, c.a.d. totalement interdites 
> aux voitures, 

un exemple est souvent utile pour expliquer ce qui ne va pas.
qu'est-ce que tu ne veux pas ?
les rues pitéonens ayant un acces temporaire pour livraison ?
si oui il suffit de rajouter le critère accès conditionnel

> ou uniquement autorisées aux résidants via des bornes rétractables

ce devient bien lourd. faut tester qu'un des noeuds est une borne
rétractable ayant un accès résident.
sauf qu'un way entre 2 bornes peux lui-même ne pas avoir de borne

Cordialement,
Marc

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


Re: [Talk-de] oneway = no

2020-05-25 Per discussione Markus via Talk-de
Hallo Florian,

>> 3 Zustände:
>> - ja
>> - nein
>> - weiss nicht
>>
>> Letzterer muss noch geprüft werden
>> (die anderen Beiden sollen regelmässig auf Änderung kontrolliert werden)
>
> Also nicht das ich nicht gerne label an Objekte hängen würde die ich
> gerne rechecken würde

Es geht nicht um eine private ToDo-Liste.
Sondern um öffentliche Qualitätsmerkmale der Daten.

Angenommen, man will möglichst valide Daten, möglichst zeitnah,
dann kommt man um eine Erfassung der Validität nicht herum.

Beispiel:

Viele schreiben "highway=track" an eine Linie, die sie aus dem Luftbild
oder aus Erinnerung vor Ort gemappt haben (weil sie nicht oder nicht
mehr genau wissen, wie das genau war, aber Lage und Form kennen).
Für den Kenner ist dadurch ersichtlich, dass noch etwas fehlt und
verbessern das wenn sie mal vor Ort sind.
(Anfänger denken, dass "track" etwas Genaues bezeichnet, sie aber nicht
genau wissen was).

Bei eindeutigen Merkmalen wie "oneway=yes" ist es klar, da steht ein
Schild. Aber wenn ich mich nur erinnere, dass dort "irgendwo" ein Schild
stand, vielleicht in einer anderen oder abzweigenden Strasse, wie kann
ich das dann angeben, damit es Dritte unterscheiden können von "da ist
(vielleicht) was" oder da ist "sicher nichts"?

Oder bei (strassen)"name=*" bei eindeutiger Ortsstrasse, deren Name ich
nicht kenne? oder bei der es gar keine Namen gibt?

Je älter OSM wird, desto problematischer werden Konflikte zwischen
"Bekannt" und "Unbekannt".

Und ja, wenn man das verbessern will:
- brauchen wir definierte Meta-tags
- wird die DB grösser

Gruss, Markus

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


Re: [Talk-at] Abzeichnen von OpenTopoMap?

2020-05-25 Per discussione Patrick Strasser-Mikhail

Hallo Friedrich!

Am 25.05.20 um 00:02 schrieb Friedrich Volkmann:

On 24.05.20 20:28, Patrick Strasser-Mikhail wrote:
Ich zeichne gerade in einer sehr spärlich gemappten Region der Welt 
grundlegende Dinge (Straßen, Gewässer, Wald/Farmland, Gebäude).


Die Lizenzfrage erübrigt sich, weil es sowieso keinen Sinn hat, 
irgendwas aus der Opentopomap abzuzeichnen. 


Du hast offensichtlich nicht nicht sorgfältig gelesen.

Ich kann deine Feststellung über "OTM ist nirgendwo hilfreich" gerne mit 
einem stichhaltigen Beispiel aus der weiten Welt entkräften. Du kannst 
aber auch meine Changesets anschauen.


Die Geländedaten sind aus SRTM, und das ist irrsinnig ungenau. 

Genau genug und das Beste für meine Region von Interesse.
Es stehen viel genauere Geländedaten (10m-Raster) als OGD zur Verfügung, 

Nicht alles ist Österreich.
und die Openslopemap nutzt diese bereits für ihre (folglich viel 
genaueren) Höhenlinien. Ich hab für Garmin-Geräte ebenfalls schon die 
genauen Höhenlinien zum Download bereitgestellt, und man könnte auch 
einen Vector-Tile-Server aufsetzen mit diesen Höhenlinien. (Hat noch 
keiner gemacht, wär aber super.)

Super, mach dass, ist aber hier nicht von Belang.
Ob ein Weg plausibel ist, siehst du aber auch mit dem 10m-Raster 
nicht, dafür aber mit dem Geländeschummerungslayer von basemap.at.
basemap.at endet an den österreichischen Grenzen, und ich habe durchaus 
Beispiele, wo ein 30m-Raster immer noch sehr hilfreich ist.

Dass Bing die beste Quelle ist, kann ich kaum glauben,

Gaub zwischendurch anderen Menschen!
In der Region, die mich interessiert gibt es ESRI und Bing, und das erst 
seit zwei Jahren. Scheinen die gleichen Bilder zu sein, aber ESRI ist 
schlecht registriert und nicht entzerrt, Bing ist besser registriert und 
brauchbar entzerrt. Auf mehreren tausend Quadratkilometer gibt es zwei 
schlechte GPX-Tracks. Bing _ist_ die beste Quelle.
denn Bing ist bekannt dafür, oft mehrere Meter daneben zu liegen, 
sogar in flachem Gelände. Kein Wunder, weil Bing das genaue amtliche 
Geländemodell und wahrscheinlich auch die Fixpunkte nicht zur 
Verfügung hat und die Luftbilder somit nicht danach ausrichten kann.
In diesem Land gibt es amtliche Karten, die 30 Jahre alt sind, und die 
ich nicht bekomme. Und das ist dann auch schon.
Verwende im Normalfall lieber geoimage.at. Bing kann aber hilfreich 
sein, wenn z.B. ein Waldweg auf geoimage.at wegen der Vegetation oder 
wegen eines schiefen Winkels nicht gut sichtbar ist. Manchmal ist er 
auf Bing besser sichtbar - aber man muss dann beim Abzeichnen den 
Versatz berücksichtigen.


Ich müsste mich wiederholen.

Friedrich, die Frage war zur Lizenz, und ab wann eine Quelle genannt 
werden muss, und ob SRTM-Daten OSM-kompatibel sind. Vielleicht hast du 
ja noch dazu eine Feststellung.


LG

Patrick


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


Re: [Talk-it] Richiesta su capacità/

2020-05-25 Per discussione Alessandro Sarretta
Grazie a tutti degli input, che mi saranno utili per dare qualche 
riferimento e indirizzo generale all'associazione, da approfondire poi 
quando avranno più chiari i loro obiettivi.


Ale


On 21/05/20 09:27, Martin Koppenhoefer wrote:



sent from a phone

On 21. May 2020, at 05:50, Alessandro Sarretta 
 wrote:


Ho visto che Switch2OSM (https://switch2osm.org/serving-tiles/) 
fornisce delle indicazioni e delle guide; sapete se ci sono altri 
portali, documenti o degli esempi di buone pratiche che descrivono 
nel dettaglio limiti e potenzialità?



con un proprio server non ci sono limiti ;-)
Non c’è una risposta semplice a questa domanda,  dipende quale siano 
le loro esigenze (mappe prerenderizzate di un singolo stile, oppure 
dinamiche (WMS ecc.), aggiornamento continuo o ogni tanto, vettoriali 
o raster, copertura Italia o globale, ecc.


Generalmente switch2osm fornisce un’idea come fare.

Ciao Martin


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