Re: [talk-au] Automated monitoring of changes to existing OSM objects - any interest?

2019-12-14 Per discussione Graeme Fitzpatrick
Just wondering if it could be done as something like MapRoulette to show
any changes?

Thanks

Graeme


On Sun, 15 Dec 2019 at 15:34, Ewen Hill  wrote:

> Recently I have been talking to someone off-list about monitoring large or
> complex relations. In his instance, he was looking to monitor a 1200km
> relation in Western Australia for any accidental vandalism and to be on top
> of any changes yet to be conveyed in the official map of the route.
>
> This was a little more complex than first imagined as the data returned
> from the data changes was so large it couldn't be loaded in memory It's
> probably due to the significant number of changes AND the significant
> number of road segments AND other shorter relations used so the import went
> on a crash diet.
>
> Each night we check for changes and email a link that allows the curator
> to review the new changes if any occur
>
> Would anyone be interested in monitoring a small collection of objects for
> changes on a daily basis? If so, let me know off-line and I may consider
> making the process more versatile and user-fed using your OSM login post
> Christmas.
>
>
> Ewen
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


[talk-au] Automated monitoring of changes to existing OSM objects - any interest?

2019-12-14 Per discussione Ewen Hill
Recently I have been talking to someone off-list about monitoring large or
complex relations. In his instance, he was looking to monitor a 1200km
relation in Western Australia for any accidental vandalism and to be on top
of any changes yet to be conveyed in the official map of the route.

This was a little more complex than first imagined as the data returned
from the data changes was so large it couldn't be loaded in memory It's
probably due to the significant number of changes AND the significant
number of road segments AND other shorter relations used so the import went
on a crash diet.

Each night we check for changes and email a link that allows the curator to
review the new changes if any occur

Would anyone be interested in monitoring a small collection of objects for
changes on a daily basis? If so, let me know off-line and I may consider
making the process more versatile and user-fed using your OSM login post
Christmas.


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


Re: [OSM-talk-fr] ref:FR:FANTOIR

2019-12-14 Per discussione Yves P.
> Pas des plus facile à calculer :)
> Je le dit à ma façon parce que pour moi c'était pas clair tout de suite sur 
> ton lien :
Je me suis bien prit la tête aussi ;-)

> Si on a un code sur 11 caractères : XXYZZZ (ici ça en fait 10 mais il 
> manque la clé a la fin)
Pour la Corse, il y a une lettre qui traine aussi dans le X

> par exemple, pour ce code 010053B003B (que l'on trouve là : 
> https://dev.cadastre.openstreetmap.fr/fantoir/index.html#insee=01053=4 
> ),
>  
> ça donne (10053*19+11*11+3)modulo 23 = 1 donc B
Bravo.

> Mais je suis pas sur que ça nous serve pour osm,
ça sert uniquement à vérifier qu’il n'y a pas d’erreur de copier/coller de la 
part du contributeur OSM.

> il faudrait mieux vérifier que les valeurs de ref:FR:FANTOIR que l'on a dans 
> osm sont bien présentes dans la source officielle.
Pourquoi pas, ça donne du boulot en perspective…

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


Re: [talk-au] 1300 / 1800 phone number format

2019-12-14 Per discussione Kim Oldfield

Wiki has been updated.

On 14/12/19 3:38 pm, Graeme Fitzpatrick wrote:


On Sat, 14 Dec 2019 at 14:34, Kim Oldfield > wrote:



My suggested rewrite is:


Thanks, Kim - that sounds much better!

Please go ahead & make the change :-)

Graeme


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


Re: [Talk-it] [talk-it] Overpass GL query per trovare tutti attraversamenti senza way con *=crossing

2019-12-14 Per discussione Lorenzo Mastrogiacomi
Il giorno sab, 14/12/2019 alle 22.20 +0100, Volker Schmidt ha scritto:
> Mi serve una query che mi trova con overpass turbo tutti i nodi con
> highway=crossing che non fanno parte di una way con
> path|cycleway|footway|track=crossing
> 
> 

Prova così
https://overpass-turbo.eu/s/OYy


Se vuoi allargare la ricerca anche ai nodi che non hanno una way di
attraversamento dovrebbe bastare sostituire il primo filtro
["highway"~"path|cycleway|footway|track"]
con
[highway]


> Grazie e una birra in anticipo

Provvidenziale ora :)


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


[Talk-it] [talk-it] Overpass GL query per trovare tutti attraversamenti senza way con *=crossing

2019-12-14 Per discussione Volker Schmidt
Mi serve una query che mi trova con overpass turbo tutti i nodi con
highway=crossing che non fanno parte di una way con
path|cycleway|footway|track=crossing

Grazie e una birra in anticipo

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


Re: [OSM-talk-fr] ref:FR:FANTOIR

2019-12-14 Per discussione Jérôme Amagat
Le sam. 14 déc. 2019 à 18:34, Yves P.  a écrit :

> @Jérôme
>
> Je n'est retrouvé nul part à part sur le wiki cette absence de I O Q (je
> n'ai pas trop cherché non plus) donc je ne m'en suis pas occupé
>
>
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
>
>- la clé de contrôle (1 lettre de l'alphabet sans I, O et Q ; ce
>caractère n'est pas distinctif mais sa présence reste recommandée).
>
>
> mais si il n'y en a qu'un dans osm c'est que ça doit être vrai.
>
> ?
> J’ai trouvée une seule valeur avec la clé incorrecte (lettre I)
> Mais en recalculant la clé et en la comparant avec celle se trouvant dans
> la valeur, on devrait vérifier qu’il n’y a pas eu d’erreur de saisie
>
> Je n'ai pas trouvé non plus comment cette lettre est obtenu. Donc
> [A-HJ-NPR-Z] ça me semble pas mal
>
> Je n’ai rien trouvé d’officiel. Heureusement quelqu’un a trouvé la réponse
> : https://georezo.net/forum/viewtopic.php?id=102292
> J’essaie de recalculer cette clé (en sachant quelle utilise le code
> direction qui ne figure plus dans OSM)
>
> Pas des plus facile à calculer :)
Je le dit à ma façon parce que pour moi c'était pas clair tout de suite sur
ton lien :

Si on a un code sur 11 caractères : XXYZZZ (ici ça en fait 10 mais il
manque la clé a la fin)
il faut faire ( XX * 19 + Y * 11 + ZZZ ) modulo 23 avec pour Y si c'est
une lettre il faut la changé en 10 pour A, 11 pour B 
Et le résultat on le change en lettre avec A pour 0, B pour 1 ... en
sautant I,O et Q

par exemple, pour ce code 010053B003B (que l'on trouve là :
https://dev.cadastre.openstreetmap.fr/fantoir/index.html#insee=01053=4),

ça donne (10053*19+11*11+3)modulo 23 = 1 donc B

C'est pas simple mais j'ai vérifié pour plusieurs valeurs dont certaine
avec un code direction différent de 0 et ça marche :)

Mais je suis pas sur que ça nous serve pour osm, il faudrait mieux vérifier
que les valeurs de ref:FR:FANTOIR que l'on a dans osm sont bien présentes
dans la source officielle.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-GB] What is farmland?

2019-12-14 Per discussione Warin

On 15/12/19 04:12, John Aldridge wrote:

On 14-Dec-19 16:52, SK53 wrote:
Like Dave I have come to the view that mapping individual fields as 
farmland is a good way to do it.


I too concur. Here's the diary entry I wrote when I was doing the 
fields round here...


I have at least some crop fields where livestock go in after harvest to 
much on the stubble... so multiple use.


https://www.openstreetmap.org/user/jpsa/diary/17738


Nice entry there John. Some of 'my' fields abut one another so there is 
no gap. Others have patches of scrub inside them, some have water ways 
part way through them. There is rather a lot of the country side here 
that is not mapped and a fair proportion of it are these crop lands. To 
give you an idea of the size .. many times the area of UK. Urban areas 
get more attention as there are more visitors and more mappers there.


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


[Talk-GB] Last Nottingham pub meeting of the year

2019-12-14 Per discussione SK53
Dear All,

We're meeting at the Lincolnshire Poacher on Mansfield Road on Tuesday 17th
from 19:30 onwards. Details on the wiki
.

This is primarily a social event for East Midland mappers, but anyone who
wishes to come & ask any kind of detailed question about OpenStreetMap is
very welcome. We have a good range of experienced contributors who can
usually give guidance on a wide range of OSM topics, from mapping to
setting up a server. Typically we discuss a range of mapping issues in the
first hour of the meeting.

The Poacher has two front bars, a snug and two areas at the rear. We try &
meet in the snug, but if that is busy then prefer one of the larger tables
in the front bar. If I remember there will be an OSM logo to help find us.

I'd like to take this opportunity to wish East Midland mappers & the
broader OSM UK community a Merry Christmas.

Cheers,

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


Re: [OSM-talk-fr] Résultat des élections au bureau de la Fondation OSM

2019-12-14 Per discussione Jacques Lavignotte



Le 14/12/2019 à 19:26, Vincent de Château-Thierry a écrit :


1. Guillaume Rischard


avec plus de 30%


--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.


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


Re: [Talk-it] Problemi con nome, acronimo o sigla in "operator"

2019-12-14 Per discussione Martin Koppenhoefer


sent from a phone

> On 14. Dec 2019, at 19:10, liste DOT girarsi AT posteo DOT eu 
>  wrote:
> 
> In questo momento non ho sottomano la discussione, ma mi sembra che in
> caso di tipologia societaria ci si sia uniformati per Pippo S.P.A..


anch‘io faccio più o meno così, normalmente faccio Pippo S.p.A. oppure  Srl. 
(ammetto non è consistente), queste sigle un consumatore di dati dovrebbe 
comunque interpretarle a prescindere del modo preciso di inserimento 

io solitamente faccio come gli uffici ;-) metto anche la partita iva, dove non 
ci sono problemi del genere 

ref:vatin=IT123456789

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


Re: [OSM-legal-talk] use OSM data to select proprietary data

2019-12-14 Per discussione Christoph Hormann
On Saturday 14 December 2019, matthias.straetl...@buerotiger.de wrote:
> > existing OSMF community guidelines suggest spatial operations like
> > ST_Difference() and ST_Intersection() yield Derivative Databases
> > that are subject to share-alike.
>
> Let's take the Collective Database Guideline, you've mentioned:
> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Coll
>ective_Database_Guideline_Guideline
>
> "Technically a reference between non-OSM and OSM data can be by a
> database key or any other method of identifying a specific OSM or
> non-OSM element that may be used with a database join."
>
> So actually, I just need to create a collective database, put the
> non-free data in one table and OSM data in another. For table
> joining, I'm using ST_Intersects() and I'm fine?

No, the quoted guideline says that share-alike does not apply if OSM
data and non-OSM data *do not* reference each other and in specific
other cases.  None of these cases covers references through spatial
relationships.

The idea that your process of intersecting non-OSM data with OSM based
admin polygons results in a collective database is not realistic.  To
me this kind of operation would be a textbook example of something
generating a derivative database - you combine OSM data with non-OSM
data to generate something of additional value compared to either of
these data sets alone.  This is exactly the kind of scenario
share-alike is meant for and why it was chosen as license for OSM.  But
there are of course fairly strong economic interests for this not being
subject to share-alike so people think of ways to interpret the ODbL
accordingly.

--
Christoph Hormann
http://www.imagico.de/

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


Re: [OSM-talk-fr] umap et fond photo IGN

2019-12-14 Per discussione Christian Quest
Voilà, c'est ajouté... si je ne l'avais pas fait plus tôt, c'est que comme
wms.openstreetmap.fr est physiquement chez moi, ma ligne VDSL n'était pas
suffisante pour un usage de ce type.

Depuis cet été j'ai deux fibres et mis de la redondance un peu partout pour
faire de l'hébergement un peu plus industriel et ça ne pose plus de
problème :)

Le sam. 14 déc. 2019 à 19:17, Cédric Frayssinet  a
écrit :

> Le 14/12/2019 à 18:43, Christian Quest a écrit :
>
> Je peux aussi ajouter le fond "openortho", mais il ne couvre pas encore
> toute la France.
>
> Je trouve que c'est une riche idée car selon les uMaps créées, cela peut
> être utile :)
>
> Merci pour tout ce travail !
>
> Cédric
> --
>
> Sur Mastodon : @bristow...@framapiaf.org
> 
>
> [image: Promouvoir et soutenir le logiciel libre] 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


Re: [OSM-legal-talk] use OSM data to select proprietary data

2019-12-14 Per discussione matthias . straetling
>
> existing OSMF community guidelines suggest spatial operations like
> ST_Difference() and ST_Intersection() yield Derivative Databases that
> are subject to share-alike.

Let's take the Collective Database Guideline, you've mentioned:
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Collective_Database_Guideline_Guideline

"Technically a reference between non-OSM and OSM data can be by a database key 
or any other method of identifying a specific OSM or non-OSM element that may 
be used with a database join."

So actually, I just need to create a collective database, put the non-free data 
in one table and OSM data in another.
For table joining, I'm using ST_Intersects() and I'm fine?

Confusing.

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


Re: [Talk-de] ÖPNV Routen Husum (Nordsee)

2019-12-14 Per discussione René Falk
Am 14. Dezember 2019 12:18:50 MEZ schrieb Michael Reichert 
:
>Hallo,
>
>Am 14/12/2019 um 11.48 schrieb goegeo:
>> Hallo zusammen, in Husum (Nordsee) wurde am 1. August ein vollkommen
>> neues Stadtbusnetz (Website: www.husumbus.de) eingeführt (geänderte
>> Routenführung und halb-/stündliche Taktung. Ich habe einige der neuen
>> Linienverkehre bereits mit erfasst – allerdings sind auch noch die
>> Altlinien noch erfasst (verschiedenene 105x). Geht das in Ordnung,
>wenn
>> ich die historischen Routenrelationen (Altlinien) einfach lösche?
>Oder
>> sollte so etwas auch über das Forum angekündigt/vorher diskutiert
>> werden? An dieser Stelle mache ich es ja jetzt schon? Hat jemand hier
>> Einwendungen
>
>Wenn die Linien ab morgen nicht mehr verkehren, kannst du ihre
>Routenrelationen ersatzlos löschen. OSM ist kein Projekt für
>historische
>Daten. Anders als bei stillgelegten Gleisen bleibt nicht mal mehr ein
>naturnahes Biotop zurück.
>
>Bitte denk daran, auch Bushaltestellen, die nicht mehr bedient werden,
>zu löschen, wenn sie abgebaut worden sind.
>
>Viele Grüße
>
>Michael

Hallo,

Ist schon sehr lange her, das ich mich mit ÖPNV befast habe. Deswegen meinen 
Post hier unter vorbehalt. Ich meine mich zu erinnern, das es für inaktive 
Bushaltestellen, die baulich nicht komplett zurückgebaut worden sind, einen 
unbenutzt/inaktiv Key zum Tag gab. Habe den Key jetzt nicht mehr im Kopf.
Manchmal ist es so, das nur das Halteschild und der Fahrplan entfernt wird, und 
der Rest der Haltestelle, z. b. die Haltebucht, bestehen bleibt.

Grüße
René

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


[OSM-talk-fr] Idée folle : changer building=service en building=utility lorsqu'applicable

2019-12-14 Per discussione François Lacombe
Salut à tous,

En faisant un peu le point sur le potentiel de la nouvelle clé utility=* et
sa sémantique, elle est généralisable à beaucoup d'objets sans trop
d'efforts (principalement les bâtiments et les street cabinet)
Elle traduit l'activité attachée à un bâtiment ou site pour l'acheminement
en énergie ou fluides en tous gens (en référence aux utilités publiques)
https://wiki.openstreetmap.org/wiki/FR:Key:utility

Je verrai bien une nouvelle valeur à building, building=utility (+
utility=*) qui aurait du sens.

Mais il y a déjà une valeur building=service, sans qu'on sache finalement
de quel service il s'agisse. On est d'ailleurs pas sûr que ce soit
restreint aux utilités, même si la documentation y fait beaucoup penser.
https://wiki.openstreetmap.org/wiki/Tag:building%3Dservice

Il y a certainement une partie de building=yes et building=industrial qui
seraient concernés aussi.

Que penseriez-vous d'introduire building=utility, remplacer
building=service quand c'est nécessaire et utiliser utility=* jusque là
pensé pour le bornage ?

Il y aura une proposition en bonne et due forme mais cela ne nous empêche
pas d'en discuter pour la France pour commencer.

Bonne soirée

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


[OSM-talk-fr] Résultat des élections au bureau de la Fondation OSM

2019-12-14 Per discussione Vincent de Château-Thierry

Ci-dessous les résultats des élections au bureau de la Fondation OSM.

Les 4 élus sont :
1. Guillaume Rischard
2. Allan Mustard
3. Mikel Maron
4. Rory McCann

(commentaire personnel : bravo Guillaume \o/)

Toutes les résolutions sont passées, sauf celle qui visait à ce qu'une 
personne ayant déjà accompli 3 mandats ne puisse plus *du tout* se 
représenter.


Sur les résolutions, plus de détails en anglais ici : 
https://wiki.osmfoundation.org/wiki/Annual_General_Meetings/2019/Suggested_AoA_Changes_revised


vincent

 Message transféré 
Sujet : [Osmf-talk] Election results
Date :  Sat, 14 Dec 2019 17:53:37 +0100
De :Frederik Ramm 
Pour :  osmf-t...@openstreetmap.org 



Quick copy & paste from IRC for those who're not there:

1. Guillaume Rischard
2. Allan Mustard
3. Mikel Maron
4. Rory McCann

Increase “rejection time frame” — passed with 93%
Increase vote eligibility lead time — passed with 83%
Introduce board eligibility lead time — passed with 90%
Board term length and term limits, part 1 of 3 — passed with 87%
Board term length and term limits, part 2 of 3 — passed with 83%
Board term length and term limits, part 3 of 3 — REJECTED with 67%
Cosmetic change to §81 — passed with 97%
Fee waiver for mappers/contributors — passed with 91%

Bye
Frederik

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

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


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


[OSM-talk-fr] !!AUX RESULTATS!! 2019 OSMF board election and proposed Membership Fee waiver change

2019-12-14 Per discussione Jacques Lavignotte

Dans votre BAL (pour ceux qui ont voté)

This email is being sent to inform you that voting has closed for the 
2019 OSMF board election and proposed Membership Fee waiver change. 
Click here to see the results.


--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.


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


Re: [OSM-talk-fr] Rendu transport routier...

2019-12-14 Per discussione Christian Quest
J'ai rendu l'affichage progressif en fonction du type de route, comme ça
dès le zoom 13 on a les restrictions sur les motorway et trunk, puis au 14
sur les primary, etc...

Avec du vectoriel on peut faire plein de combinaisons, mais là, la commande
c'est raster ;)

Le sam. 14 déc. 2019 à 18:53, Yves P.  a écrit :

> Merci pour vos retours !
>
> Pour des limitations ponctuelles, genre hauteur limite sous un pont, le
> panneau de limitation est très lisible.
> http://osm.cquest.org/fortissimo/#16/48.8847/2.3755
>
> Par contre, pour des segments plus long, ça l’est nettement moins :
> Boulevard périphérique
> http://osm.cquest.org/fortissimo/#15/48.9021/2.3570
> http://osm.cquest.org/fortissimo/#16/48.9009/2.3593
> http://osm.cquest.org/fortissimo/#17/48.90129/2.35922
> http://osm.cquest.org/fortissimo/#18/48.90140/2.35878
>
> Il faudrait le panneau qu’une seule fois, ou à défaut, des couleurs
> différentes (mais ça risque d’être compliqué) ?
>
> Est-ce possible de faire un rendu personnalisé en superposant plusieurs
> couches ?
> J’ai un camion de 15t et de 3m de haut.
> J’affiche la couche ≥3m et la couche ≥15t. Je pourrais afficher aussi la
> couche matières dangereuse si mon camion en transporte.
>
> En bitmap ça risque de faire beaucoup de combinaisons ??
> En vectoriel, c’est peut-être jouable. Mais peut-on superposer une couche
> vectorielle à une couche bitmap dans leaflet ou dans  OpenLayers ?
>
> Je découvre du coup de valeurs pas très catholiques dans ces tags !
>
> Tu as des exemples ?
>
> —
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


Re: [OSM-talk-fr] umap et fond photo IGN

2019-12-14 Per discussione Cédric Frayssinet
Le 14/12/2019 à 18:43, Christian Quest a écrit :
> Je peux aussi ajouter le fond "openortho", mais il ne couvre pas
> encore toute la France.

Je trouve que c'est une riche idée car selon les uMaps créées, cela peut
être utile :)

Merci pour tout ce travail !

Cédric

-- 

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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


Re: [OSM-talk-fr] umap et fond photo IGN

2019-12-14 Per discussione deuzeffe

Le 14/12/2019 à 18:43, Christian Quest a écrit :

Le fond BD Ortho dans umap a été ajouté car un responsable du géoportail 
avait créé une clé pour cela, une clé sans statut officiel. Je viens de 
la renouveler.


Merci à toi pour le renouvellement et l'explication.

--
deuzeffe

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


Re: [Talk-it] Problemi con nome, acronimo o sigla in "operator"

2019-12-14 Per discussione liste DOT girarsi AT posteo DOT eu
Il 14/12/19 18:26, francesco gargano ha scritto:
> Linee guida per decidere il valore da inserire in "operator":
> -nome esteso?
> -nome esteso con tipologia societaria per esteso? ("Pippo Società per
> Azioni" etc)
> -nome esteso con tipologia societaria punteggiata? ("s.p.a." "spa" "SpA"
> "S.p.A." etc..)
> -acronimo, acronimo punteggiato,acronimo con MAIUSCOLE?
> -acronimo con tipologia societaria per esteso?
> -acronimo con tipologia societaria punteggiato?
> -inserire tutte queste alternative nella voce estesa su wikidata?
> 
> "cotral" http://overpass-turbo.eu/s/OYd
> "Cotral" http://overpass-turbo.eu/s/OYf
> "COTRAL" http://overpass-turbo.eu/s/OYi
> "Co.Tra.L" http://overpass-turbo.eu/s/OYb
> "Co.Tra.L."http://overpass-turbo.eu/s/OYc
> 
> "atac" http://overpass-turbo.eu/s/OYk
> "Atac" http://overpass-turbo.eu/s/OYl
> "ATAC" http://overpass-turbo.eu/s/OYm
> 

In questo momento non ho sottomano la discussione, ma mi sembra che in
caso di tipologia societaria ci si sia uniformati per Pippo S.P.A..


-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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


Re: [OSM-talk-fr] Rendu transport routier...

2019-12-14 Per discussione Yves P.
> Merci pour vos retours !
Pour des limitations ponctuelles, genre hauteur limite sous un pont, le panneau 
de limitation est très lisible.
http://osm.cquest.org/fortissimo/#16/48.8847/2.3755

Par contre, pour des segments plus long, ça l’est nettement moins : Boulevard 
périphérique
http://osm.cquest.org/fortissimo/#15/48.9021/2.3570 

http://osm.cquest.org/fortissimo/#16/48.9009/2.3593 

http://osm.cquest.org/fortissimo/#17/48.90129/2.35922 

http://osm.cquest.org/fortissimo/#18/48.90140/2.35878 


Il faudrait le panneau qu’une seule fois, ou à défaut, des couleurs différentes 
(mais ça risque d’être compliqué) ?

Est-ce possible de faire un rendu personnalisé en superposant plusieurs couches 
?
J’ai un camion de 15t et de 3m de haut.
J’affiche la couche ≥3m et la couche ≥15t. Je pourrais afficher aussi la couche 
matières dangereuse si mon camion en transporte.

En bitmap ça risque de faire beaucoup de combinaisons ??
En vectoriel, c’est peut-être jouable. Mais peut-on superposer une couche 
vectorielle à une couche bitmap dans leaflet ou dans  OpenLayers ?

> Je découvre du coup de valeurs pas très catholiques dans ces tags !
Tu as des exemples ?

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


Re: [OSM-talk-fr] Rendu transport routier...

2019-12-14 Per discussione Christian Quest
Oui, trop d'agrégations... par contre, je peux laisser les traces
transparentes sur les voies concernées, au moins ça montre qu'il y a une
restriction, et comme on n'est pas sur du papier il ne reste plus qu'à
zoomer ;)

C'est forcément imparfait... mais ça aide !

Je ne prends pour l'instant en compte que ces tags sur les linéaires, pas
en ponctuel.
Je m'arrête aussi au residential, donc rien de visible sur
highway=service... que je pourrais rendre visible aux plus forts zoom.


Le sam. 14 déc. 2019 à 18:45, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> Le 14/12/2019 à 18:29, Christian Quest a écrit :
> >
> > Voici ce que ça donne:
> http://osm.cquest.org/fortissimo/#15/48.8324/2.3837
>
> C'est parlant :)
>
> C'est volontaire de ne démarrer qu'aux zooms 14/15 ? Tu n'as pas trouvé
> de manière satisfaisante de dessiner les restrictions aux zooms plus
> faibles ? Trop d'agrégation en certains endroits ?
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


Re: [OSM-talk-fr] umap et fond photo IGN

2019-12-14 Per discussione Christian Quest
La convention IGN/OSM ne permet d'utiliser la BD Ortho QUE POUR MAPPER.

Le fond BD Ortho dans umap a été ajouté car un responsable du géoportail
avait créé une clé pour cela, une clé sans statut officiel. Je viens de la
renouveler.

L'utilisation sur un site non commercial de la BD Ortho avec un nombre de
requêtes ne dépassant pas une certaine limite (2 millions), est possible
pour n'importe qui. C'est même une clé de ce type qui est prédéfinie sur
umap.
Chacun peut obtenir gratuitement une telle clé et définir dans umap un fond
spécifique avec la bonne URL pour ne pas utiliser la clé par défaut.

Je peux aussi ajouter le fond "openortho", mais il ne couvre pas encore
toute la France.

Un lot de mise à jour a été publié sur le site de l'IGN pour les ortho-hr,
je suis en train de les récupérer, retraiter, intégrer sur
wms.openstreetmap.fr (ce qui va prendre plusieurs jours voire semaines).
J'ai aussi expédié un disque-dur ce matin pour récupérer l'ortho de la
loire atlantique à 10cm.

Ces orthos sont auto-hébergées sur mon magnifique datacenter résidentiel à
qui j'ai même donné un nom (historique): https://www.computel.fr/


Le sam. 14 déc. 2019 à 15:04, deuzeffe  a écrit :

> Hello,
>
> Umap n'affiche plus le fond photo IGN depuis la màj de l'hébergement de
> leurs services.
>
> Si le groupe tech a 2 minutes pour comprendre pourquoi et y remédier si
> c'est possible, merci d'avance !
>
> (si je traduis la réponse de Donat sur le forum c'est "On n'a pas le
> droit de l'utiliser, c'est pour ça". J'avoue que je ne sais pas si la
> màj de l’hébergement a aussi màj la licence.)
>
> --
> deuzeffe
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


Re: [OSM-talk-fr] Rendu transport routier...

2019-12-14 Per discussione Vincent de Château-Thierry

Bonjour,

Le 14/12/2019 à 18:29, Christian Quest a écrit :


Voici ce que ça donne: http://osm.cquest.org/fortissimo/#15/48.8324/2.3837


C'est parlant :)

C'est volontaire de ne démarrer qu'aux zooms 14/15 ? Tu n'as pas trouvé 
de manière satisfaisante de dessiner les restrictions aux zooms plus 
faibles ? Trop d'agrégation en certains endroits ?


vincent

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


Re: [OSM-talk-fr] ref:FR:FANTOIR

2019-12-14 Per discussione Yves P.
@Jérôme
> Je n'est retrouvé nul part à part sur le wiki cette absence de I O Q (je n'ai 
> pas trop cherché non plus) donc je ne m'en suis pas occupé 

https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
la clé de contrôle (1 lettre de l'alphabet sans I, O et Q ; ce caractère n'est 
pas distinctif mais sa présence reste recommandée).

> mais si il n'y en a qu'un dans osm c'est que ça doit être vrai.
?
J’ai trouvée une seule valeur avec la clé incorrecte (lettre I)
Mais en recalculant la clé et en la comparant avec celle se trouvant dans la 
valeur, on devrait vérifier qu’il n’y a pas eu d’erreur de saisie

> Je n'ai pas trouvé non plus comment cette lettre est obtenu. Donc 
> [A-HJ-NPR-Z] ça me semble pas mal

Je n’ai rien trouvé d’officiel. Heureusement quelqu’un a trouvé la réponse : 
https://georezo.net/forum/viewtopic.php?id=102292 

J’essaie de recalculer cette clé (en sachant quelle utilise le code direction 
qui ne figure plus dans OSM)

—
Yves

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


[OSM-talk-fr] Rendu transport routier...

2019-12-14 Per discussione Christian Quest
Je travaille depuis quelques temps sur un rendu destiné au transport
routier.

Je finalise une couche en overlay qui rend visible les restrictions:
- maxheight
- maxweight
- maxwidth
- hgv/goods
- hazmat

Voici ce que ça donne: http://osm.cquest.org/fortissimo/#15/48.8324/2.3837

Je découvre du coup de valeurs pas très catholiques dans ces tags !
Comme quoi, dès qu'on rend visible certaines données OSM...

Le fond est une variation du style pianoforte (de ybon) qui comporte plus
d'éléments visibles et fait ressortir aussi les zones industrielles,
commerciales, chantiers. Son petit nom: fortissimo

Merci pour vos retours !
-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[Talk-it] Problemi con nome, acronimo o sigla in "operator"

2019-12-14 Per discussione francesco gargano
Linee guida per decidere il valore da inserire in "operator":
-nome esteso?
-nome esteso con tipologia societaria per esteso? ("Pippo Società per
Azioni" etc)
-nome esteso con tipologia societaria punteggiata? ("s.p.a." "spa" "SpA"
"S.p.A." etc..)
-acronimo, acronimo punteggiato,acronimo con MAIUSCOLE?
-acronimo con tipologia societaria per esteso?
-acronimo con tipologia societaria punteggiato?
-inserire tutte queste alternative nella voce estesa su wikidata?

"cotral" http://overpass-turbo.eu/s/OYd
"Cotral" http://overpass-turbo.eu/s/OYf
"COTRAL" http://overpass-turbo.eu/s/OYi
"Co.Tra.L" http://overpass-turbo.eu/s/OYb
"Co.Tra.L."http://overpass-turbo.eu/s/OYc

"atac" http://overpass-turbo.eu/s/OYk
"Atac" http://overpass-turbo.eu/s/OYl
"ATAC" http://overpass-turbo.eu/s/OYm
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [OSM-talk-fr] ref:FR:FANTOIR

2019-12-14 Per discussione Xavier BIZOT
Merci Jérôme 

Xavier

> Le 14 déc. 2019 à 18:16, Jérôme Amagat  a écrit :
> 
> 
> 
> 
>> Le sam. 14 déc. 2019 à 12:40, XavierBizot22440  
>> a écrit :
>> La ref:FR:FANTOIR est à renseigner dans le tag highway nous sommes d’accord ?
>> 
>> Sur ma commune je l’ai inséré dans la relation et non dans le highway est-ce 
>> convenable ? ou surtout pas ?
>> 
> Dans la relation, c'est ce qu'il faut faire. sauf si elle n'existe pas alors 
> sur le way.
> 
> 
> "Et en plus incomplète : elle n’exclue pas les caractères I, O et Q de la clé 
> de contrôle.
> Elle devrait donc se terminer par [A-HJ-NPR-Z]$ ou par [^IOQ0-9a-z?]$
> 
> Dans les données, je n’en ai trouvé qu’une (et il manque 1 caractère) : 
> 12300340I
> 
> De plus, on devrait vérifier la validité de la valeur FANTOIR en recalculant 
> la clé.
> L’algorithme est-il publié quelque part ?"
> 
> Je n'est retrouvé nul part à part sur le wiki cette absence de I O Q (je n'ai 
> pas trop cherché non plus) donc je ne m'en suis pas occupé mais si il n'y en 
> a qu'un dans osm c'est que ça doit être vrai. Je n'ai pas trouvé non plus 
> comment cette lettre est obtenu. Donc [A-HJ-NPR-Z] ça me semble pas mal
> 
> Et bien vu la recherche sur taginfo, je n'y avais pas pensé.
> 
> ___
> 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] ref:FR:FANTOIR

2019-12-14 Per discussione Jérôme Amagat
Le sam. 14 déc. 2019 à 12:40, XavierBizot22440 
a écrit :

> La ref:FR:FANTOIR est à renseigner dans le tag highway nous sommes
> d’accord ?
>
> Sur ma commune je l’ai inséré dans la relation et non dans le highway
> est-ce convenable ? ou surtout pas ?
>
> Dans la relation, c'est ce qu'il faut faire. sauf si elle n'existe pas
alors sur le way.


"Et en plus incomplète : elle n’exclue pas les caractères I, O et Q de la
clé de contrôle.
Elle devrait donc se terminer par [A-HJ-NPR-Z]$ ou par [^IOQ0-9a-z?]$

Dans les données, je n’en ai trouvé qu’une (et il manque 1 caractère)
: 12300340I

De plus, on devrait vérifier la validité de la valeur FANTOIR en
recalculant la clé.
L’algorithme est-il publié quelque part ?"

Je n'est retrouvé nul part à part sur le wiki cette absence de I O Q (je
n'ai pas trop cherché non plus) donc je ne m'en suis pas occupé mais si il
n'y en a qu'un dans osm c'est que ça doit être vrai. Je n'ai pas trouvé non
plus comment cette lettre est obtenu. Donc [A-HJ-NPR-Z] ça me semble pas mal

Et bien vu la recherche sur taginfo, je n'y avais pas pensé.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-GB] What is farmland?

2019-12-14 Per discussione John Aldridge

On 14-Dec-19 16:52, SK53 wrote:
Like Dave I have come to the view that mapping individual fields as 
farmland is a good way to do it.


I too concur. Here's the diary entry I wrote when I was doing the fields 
round here...


https://www.openstreetmap.org/user/jpsa/diary/17738

Cheers,
John

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


[Talk-de] OSMF-Wahlergebnis

2019-12-14 Per discussione Frederik Ramm
Hallo,

das Wahlergebnis:

1. Guillaume Rischard
2. Allan Mustard
3. Mikel Maron
4. Rory McCann

Die Satzungsänderungen sind alle angenommen, bis auf die 3. der drei
Term-Limit-Abstimmungen, das bedeutet, dass jemand nach einer Pause
wieder antreten kann, auch wenn er 6 Jahre im Board war.

Bye
Frederik

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

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


Re: [Talk-GB] What is farmland?

2019-12-14 Per discussione SK53
Like Dave I have come to the view that mapping individual fields as
farmland is a good way to do it.

I use farmland=arable & farmland=pasture. This still does not cover cases
of permanent grassland which are not used for pasture. I can see the value
of farmland=livestock for things like pig rearing which I have never tried
to map (largely because I think they move around).

The advantage of doing it field by field is that one can use real local
knowledge from surveys, can discriminate between fields which are
apparently similar on aerial imagery, can add more detailed tagging (for
instance I have used some plant community tagging in one or two areas, or
one can mark pastures with ridge and furrow). The absence of large polygons
is of course a significant benefit.

Meadow as a synonym for any old bit or rural grassland creates huge
problems if we ever want to identify real meadows which are one of the
scarcest habitats in Britain now. Such usage also covers a range of quite
different things. It is well established that people no longer know what a
true meadow looks like, but I'd hope we can be more sophisticated. Most
meadows will be available in various classes of Natural England habitat
open data. CRW have similar datasets, as do SNH. Unfortunately nothing is
available for Northern Ireland, although I've been informed by a former
head of the NIEA that Perennial Ryegrass is now the national plant : in
other words most agricultural grassland is heavily improved whether as
pasture or as leys for silage crops.

W.r.t. Mark's point, there are open data

from RPA for the past few years on agricultural usage, so it is possible to
use a bit more than guesswork. Note also much aerial imagery in the
countryside may be significantly out-of-date. I've both walked through
areas which look like arable on aerials with sheep on them and areas of
pasture have subsequently been ploughed (notably on what was formerly part
of Muston Meadows NNR). The RPA data at least allows a more up-to-date
picture. It's a hexgrid derived from remote sensing, but in most cases can
be interpreted.

Regards,

Jerry

On Sat, 14 Dec 2019 at 16:24, Edward Catmur via Talk-GB <
talk-gb@openstreetmap.org> wrote:

> Some mappers use meadow for permanent pasture, on the basis that this is a
> fundamentally different use of land to putting it under the plough.
>
> Others believe that meadow should be reserved for "real" meadow, and that
> permanent pasture should be distinguished from cropland by some combination
> of sub tags.
>
> On Sat, 14 Dec 2019, 16:09 Martin Wynne,  wrote:
>
>> > I would say yes, as I believe both arable & livestock is farmland.
>>
>> Thanks Dave.
>>
>> But in that case, how on OSM do we differentiate between the two?
>>
>> It seems silly that in some areas of OSM we can go into ridiculous
>> detail, such as whether a bench seat has a backrest, but vast tracts of
>> land which visually look very different are classed as one and the same?
>>
>> cheers,
>>
>> Martin.
>>
>> ___
>> 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
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] What is farmland?

2019-12-14 Per discussione Edward Catmur via Talk-GB
Some mappers use meadow for permanent pasture, on the basis that this is a
fundamentally different use of land to putting it under the plough.

Others believe that meadow should be reserved for "real" meadow, and that
permanent pasture should be distinguished from cropland by some combination
of sub tags.

On Sat, 14 Dec 2019, 16:09 Martin Wynne,  wrote:

> > I would say yes, as I believe both arable & livestock is farmland.
>
> Thanks Dave.
>
> But in that case, how on OSM do we differentiate between the two?
>
> It seems silly that in some areas of OSM we can go into ridiculous
> detail, such as whether a bench seat has a backrest, but vast tracts of
> land which visually look very different are classed as one and the same?
>
> cheers,
>
> Martin.
>
> ___
> 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-GB] What is farmland?

2019-12-14 Per discussione Dave F via Talk-GB

On 14/12/2019 16:08, Martin Wynne wrote:

I would say yes, as I believe both arable & livestock is farmland.


Thanks Dave.

But in that case, how on OSM do we differentiate between the two?


I would have said farmland=arable/livestock, but it doesn't appear to be 
that popular.Have you searched the wiki or 
https://taginfo.openstreetmap.org/search?q=livestock#values ?




It seems silly that in some areas of OSM we can go into ridiculous 
detail, such as whether a bench seat has a backrest, but vast tracts 
of land which visually look very different are classed as one and the 
same?


You can map in as much detail as you like. northing's really stopping 
you. Others haven't, I'd suggest, because it's 'over there' - Cities, 
where most benches are, are also where the most mappers are. People will 
almost always map what's on their doorstep as a priority.


Cheers
DaveF

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


Re: [Talk-GB] What is farmland?

2019-12-14 Per discussione Mark Goodge



On 14/12/2019 16:08, Martin Wynne wrote:

I would say yes, as I believe both arable & livestock is farmland.


Thanks Dave.

But in that case, how on OSM do we differentiate between the two?

It seems silly that in some areas of OSM we can go into ridiculous 
detail, such as whether a bench seat has a backrest, but vast tracts of 
land which visually look very different are classed as one and the same?


That's partly because our mappers tend to be more urban, and urban 
things are what they tend to care more about and have more knowledge 
about. But, also, it's often hard to map rural areas from observation as 
a lot of it is private property that can't easily be accessed other than 
along the route of public rights of way. So we're more reliant on the 
aerial imagery for a lot of the countryside, and in many cases it's 
impossible to tell the difference between arable and grassland as it's 
all just shades of green (or, in summer, brown). In the same way, you 
can't easily see field boundaries on aerial photography unless they're 
separated by something easily visible, such as a hedgerow.


So I don't think this is an easily solvable problem, at least not 
without a lot of groundwork and local knowledge.


Mark

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


Re: [Talk-GB] What is farmland?

2019-12-14 Per discussione Dan S
Op za 14 dec. 2019 om 16:09 schreef Martin Wynne :
>
> > I would say yes, as I believe both arable & livestock is farmland.
>
> Thanks Dave.
>
> But in that case, how on OSM do we differentiate between the two?

using an added tag farmland=*

https://taginfo.openstreetmap.org.uk/keys/farmland


> It seems silly that in some areas of OSM we can go into ridiculous
> detail, such as whether a bench seat has a backrest, but vast tracts of
> land which visually look very different are classed as one and the same?

The bench-with-backrest is a good example: generic tags for generic
tagging, and the possibly to add more detailed tags progressively.

Cheers
Dan

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


Re: [Talk-GB] What is farmland?

2019-12-14 Per discussione Martin Wynne

I would say yes, as I believe both arable & livestock is farmland.


Thanks Dave.

But in that case, how on OSM do we differentiate between the two?

It seems silly that in some areas of OSM we can go into ridiculous 
detail, such as whether a bench seat has a backrest, but vast tracts of 
land which visually look very different are classed as one and the same?


cheers,

Martin.

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


Re: [Talk-GB] What is farmland?

2019-12-14 Per discussione Dave F via Talk-GB

On 14/12/2019 15:19, Martin Wynne wrote:


Is this "farmland"?

 http://85a.uk/haws_hill_960x600.jpg


I would say yes, as I believe both arable & livestock is farmland.

I concur with your frustration about 'huge multi polygons', especially 
when joined to other features such as roads & rivers. I believe a few 
mappers were keen to fill in the gaps rather than map accurately. 
Personally I think there should be one polygon per field, but I admit 
that makes for a lot more work.


Cheers
DaveF

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


[Talk-GB] What is farmland?

2019-12-14 Per discussione Martin Wynne
My understanding of "farmland" is fields of arable land used for the 
growing of crops.


Vast areas of OSM have been marked in this area as "farmland", often as 
huge multipolygons which are difficult to edit in the iD editor.


On the standard map it creates massive chunks of single colour which 
don't represent the true patchwork nature of the countryside.


A lot of the land is not suitable for the growing of crops, and is only 
ever used as pasture for cattle or sheep. I would tend to call that a 
meadow. Some of it is too uneven, too high, too steep, soil too poor, 
for cultivation. I would tend to call that grassland or heath.


Is this "farmland"?

 http://85a.uk/haws_hill_960x600.jpg

If not, what should it be mapped as?

On the right the ground rises steeply to a wooded hilltop. On the left 
is a farmyard and beyond that fields of crops.


Martin.

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


Re: [OSM-talk-fr] Appel à l'aide à propos d'une série de premières contributions assez catastrophiques

2019-12-14 Per discussione Cédric Frayssinet
Le 14/12/2019 à 14:53, Vincent Bergeot a écrit :
>
> - recenser les extraits relatifs à OSM que l'on trouve dans les
> différents manuels scolaires, pour voir ce que raconte les manuels !!!
>
ça, je peux m'en occuper, j'ai 6 spécimens en ma possession.

Concernant les bonnes pratiques, j'ai fait un article sur le site de la
DANE, c'est plus facile à partager :
https://dane.ac-lyon.fr/spip/Les-bonnes-pratiques-pour

Cédric

-- 

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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


Re: [OSM-legal-talk] use OSM data to select proprietary data

2019-12-14 Per discussione Frederik Ramm
Hi,

On 14.12.19 06:41, Mateusz Konieczny wrote:
> Can you point me to legal definition
> of "substantial part"?

There is none, hence:
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline

Bye
Frederik

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

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


[OSM-talk-fr] umap et fond photo IGN

2019-12-14 Per discussione deuzeffe

Hello,

Umap n'affiche plus le fond photo IGN depuis la màj de l'hébergement de 
leurs services.


Si le groupe tech a 2 minutes pour comprendre pourquoi et y remédier si 
c'est possible, merci d'avance !


(si je traduis la réponse de Donat sur le forum c'est "On n'a pas le 
droit de l'utiliser, c'est pour ça". J'avoue que je ne sais pas si la 
màj de l’hébergement a aussi màj la licence.)


--
deuzeffe

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


Re: [OSM-talk-fr] Appel à l'aide à propos d'une série de premières contributions assez catastrophiques

2019-12-14 Per discussione Vincent Bergeot

Le 11/12/2019 à 21:23, Cédric Frayssinet a écrit :
Je vous informe que suite aux mauvaises contributions marseillaises, 
un courriel est parti dans toutes les DANE (Délégation Académique au 
Numérique Éducatif) de France. Il a été envoyé ce matin et il devrait 
redescendre chez tous les enseignants de SNT en académie.


Je vous le mets pour info là : 
https://cloud.mesdatas.org/s/omfk7aoefegrHFA


Il a été validé par certaines membres du CA OSM-Fr et notamment 
Vincent Bergeot.


Grand merci Cédric pour le boulot que tu as fait, ainsi que les divers 
relecteurs-contributeurs (Donat, Papa_Yankee-Bzh, GAllegre, Num, 
bristow, zebobs, Cdrik, Romain, deuzeffe, Zimmy)


Parmi les étapes suivantes en tête (oui en tête, le passage dans le réel 
est parfois complexe) :


- article sur osm-fr

- page sur le wiki autour des activités organisées, avec le courrier de 
cédric, le guide des bonnes pratiques dans un premier temps


- faire travailler quelques étudiants sur des ressources pédagogiques à 
destination des enseignants et élèves


- recenser les extraits relatifs à OSM que l'on trouve dans les 
différents manuels scolaires, pour voir ce que raconte les manuels !!!



à plus




J'ai déjà été contacté, et notamment par un auteur du manuel Bordas 
qui avait vu arriver les soucis possibles.


Espérons que cela ait un effet positif, n'hésitez pas à remonter les 
éventuels soucis.


Cédric


Le 10/12/2019 à 17:50, Donat ROBAUX a écrit :

Depuis samedi, je me suis amusé à passer en revue les contributions des gens
ayant cliqué sur "Je demande que ma contribution soit vérifiée" avec OSMCha
et les filtres qui vont bien.
J'ai contrôlé depuis début novembre uniquement en IdF.
J'étais un peu étonné car toutes les contributions étaient toutes dans le
coin des Mureaux (78). J'ai eu la réponse hier avec SNT dans le changeset.
J'ai demandé aux élèves qu'ils envoient leur prof sur le forum.

Globalement les erreurs sont:
- tag name=boulangerie à la place du tag normalement attendu
- comme ils sont sur Id, ils ajoutent tous l'adresse, CP, ville...
- ils suppriment le tag source
- orthographe/typographie
- commentaire à la google: "je recommande ce resto, pas cher,..."
- doublon de magasins

Ils avaient tous un username perso, c'est pourquoi je n'ai pas repéré de
suite le SNT. Ils ont quand même ajouté des trucs utiles.

A chaque fois je leur mets la page
https://wiki.openstreetmap.org/wiki/FR:Bonnes_pratiques  en espérant que ca
serve.

Donat




--
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



--

Sur Mastodon : @bristow...@framapiaf.org 



Promouvoir et soutenir le logiciel libre 


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



--
Vincent Bergeot

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


Re: [OSM-talk-fr] ref:FR:FANTOIR

2019-12-14 Per discussione Yves P.
@Donat
> /ref:FR:FANTOIR_1 et ref:FR:FANTOIR:2 doivent être supprimé après avoir
> rajouté les valeurs dans ref:FR:FANTOIR
> /
> Si y a 1 et 2, c'est que y a un truc qui rentre pas dans les cases.
C’est peut-être aussi parce qu’iD n’aime pas les valeurs multiples et qu’il 
crée des clés à la con.

https://overpass-turbo.eu/s/OXO 

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


Re: [OSM-talk-fr] ref:FR:FANTOIR

2019-12-14 Per discussione Yves P.

> J’ai regardé très rapidement. Elle est assez compliquée 
Et en plus incomplète : elle n’exclue pas les caractères I, O et Q de la clé de 
contrôle.
Elle devrait donc se terminer par [A-HJ-NPR-Z]$ ou par [^IOQ0-9a-z?]$

Dans les données, je n’en ai trouvé qu’une (et il manque 1 caractère) : 
12300340I

De plus, on devrait vérifier la validité de la valeur FANTOIR en recalculant la 
clé.
L'algorythme est-il publié quelque part ?


J’en revient à la proposition de Jérôme de mettre des « contraintes » dans 
l’espace wikidata d’OSM.
Pour la contrainte, on pourrait indiquer si les valeurs multiples (séparées par 
des ;) sont autorisées pour cette clé.
Et a terme (un jour ), ça serait bien que les éditeurs, taginfo, le site 
d’OSM… tiennent compte de ça.
Du coup, l’expression régulière serait plus simple (elle ne traite que la 
valeur individuelle).

D’une façon plus générale, ça veut dire que les infos box dans le wiki 
prendraient leurs valeurs depuis ces wikidata ?
Et que tout  les outils (éditeurs, contrôleur qualité…) utiliseront cette base 
de donnée sémantique ?
Et rêvons encore un peu (c’est bientôt Noël ), les liens vers les identifiants 
externes apparaitront tout seuls sans avoir à faire de PR

—
Yves

 

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


[OSM-talk-fr] transports en commun, opendata, trajets, références ...

2019-12-14 Per discussione Cyrille37 OSM

Hello,

Pour avis, meilleur compréhension (débat ?) :

Sur https://transport.data.gouv.fr on peut trouver les données d'une 
offre de transport théorique (lignes, arrêts, horaires) au format GTFS.


Je m'interroge donc sur la pertinence d'avoir certaines données (ex: 
trajets) dans OSM, vu le travail important de mise à jour et qui n'est 
pas toujours fait.


Par contre pour ce qui est de la description fine dans OSM des arrêts et 
plateformes, que penser de leur association avec des références 
indiquées dans les données transport.data.gouv.fr, comme par exemple 
"StopPoint : TTRVAPRB-1".


Merci de vos lumières,
Cyrille37.


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


Re: [OSM-legal-talk] use OSM data to select proprietary data

2019-12-14 Per discussione Robert Whittaker (OSM lists)
On Thu, 12 Dec 2019 22:41 Kathleen Lu via legal-talk, <
legal-talk@openstreetmap.org> wrote:

> No, ODbL does not apply to any database that does not include OSM data.
> There are two reasons.
>

I would argue that the dataset here does include some OSM data, as it includes
(albeit limited) information about the regions enclosed by certain features
in OSM. Regardless of that though, I would use the following reasoning,
involving a chain of derivative databases, to argue that final databases
could be subject to ODbL even if they don't directly contain any OSM data,
if OSM data has been used in their creation.

At some point in the process of deriving the new dataset here, an OSM extract
and some proprietary data were combined into a database. To start with,
these would be independent parts, and so the combined database would be a
Collective Database, and so not subject to ODbL.
However, I would argue that the moment you run a query that combines both
parts of the database in a non-trivial way, those parts can no longer be
said to be "independent", and hence they cannot be part of a
Collective Database. The combined OSM extract, proprietary data, and the
output from the query are now a derivative database, and hence subject to
ODbL, thanks to the presence of the OSM data. The data published is then a
substantial extract from this derivative database,
and is thus is a derivative of the derivative. This makes it also subject
to ODbL.

Robert.

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


Re: [OSM-talk-fr] ref:FR:FANTOIR

2019-12-14 Per discussione XavierBizot22440
La ref:FR:FANTOIR est à renseigner dans le tag highway nous sommes d’accord ?

Sur ma commune je l’ai inséré dans la relation et non dans le highway est-ce 
convenable ? ou surtout pas ?

Merci

> Le 14 déc. 2019 à 12:23, Christian Quest  a écrit :
> 
> Clairement aucune de mon point de vue.
> 
> De plus, ces réorganisations futures de la DGFiP peuvent modifier ce code de 
> direction alors que le reste ne changera pas... je ne vois que des 
> inconvénients à se créer une dépendance sur quelque chose qu'on n'utilise 
> pas, qui n'a pas de rapport avec le sujet et qui peut changer sans prévenir.
> 
> Même choix fait par l'AITF pour le format d'échange des Bases Adresses 
> Locales, et du coup la clé d'interopérabilité qui se trouve aussi dans les 
> fichiers BAN.
> 
> 
> Le jeu. 12 déc. 2019 à 22:14, Vincent de Château-Thierry  > a écrit :
> Bonsoir,
> 
> Le 11/12/2019 à 21:53, deuzeffe a écrit :
> > Le 11/12/2019 à 05:10, Jérôme Amagat a écrit :
> >> Bonjour,
> >>
> >> D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=* 
> >> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR 
> >> 
> >> Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
> >> https://overpass-turbo.eu/s/OSX 
> > 
> > D'après la description du fichier FANTOIR 
> > (https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e
> >  
> > 
> >  
> > ) c'est 11. Sauf que le code direction - fiscale ? - (deuxième "champ") 
> > semble avoir été ràz, donc ignoré dans la version finale ?
> > 
> > Si quelqu'un y voit plus clair que moi...
> 
> Disons que dans OSM depuis au moins le début de BANO (mi 214) on a 
> choisi de ne pas considérer ce code direction pour composer ce qu'on 
> appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement 
> appliquée depuis, et assez pratique puisqu'elle permet très simplement 
> un lien avec la commune, vu que les 5 1ères positions du code 
> correspondent au code INSEE communal. Je ne sais pas quel avantage / 
> quelle interopérabilité nous apporterait l'inclusion du code direction 
> en 3è position, je sais en revanche qu'il nous casserait bien les pieds 
> à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR 
> et sa commune d'appartenance. On passerait notre temps à détricoter le 
> ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...
> 
> vincent
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr 
> 
> 
> 
> -- 
> Christian Quest - OpenStreetMap France
> ___
> 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] ref:FR:FANTOIR

2019-12-14 Per discussione Donat ROBAUX
Bonjour,

Je viens de regarder également.

/ref:fantoir et ref:FR:fantoir doivent être renommés en ref:FR:FANTOIR/

*/ref:fantoir/. J'ai regardé, c'est pas du tout lié à Fantoir. J'ai laissé
un com dans le changeset
*/ref:FR:fantoir/. Sur celle de Brest, c'est le code voie qui est mis sur
chaque adresse. Mais ca a été fait en 2012. Je n'y ai pas touché. Je serai
partant pour envoyer un message au contributeur unique de tout ca, même si
il a pas contribué depuis 1 an.
Par contre j'ai corrigé manuellement les autres ailleurs en France, sauf
Toulouse.

/ref:FR:FANTOIR_1 et ref:FR:FANTOIR:2 doivent être supprimé après avoir
rajouté les valeurs dans ref:FR:FANTOIR
/
Si y a 1 et 2, c'est que y a un truc qui rentre pas dans les cases.

ref:right:FR:FANTOIR doit être renommé en ref:FR:FANTOIR:right

Ca j'ai corrigé

Pour les /source:ref:fantoir/, je pense qu'on peut les enlever, ca n'apporte
rien.

Je crois n'avoir rien oublié
Donat



--
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


Re: [OSM-talk-fr] ref:FR:FANTOIR

2019-12-14 Per discussione Christian Quest
Clairement aucune de mon point de vue.

De plus, ces réorganisations futures de la DGFiP peuvent modifier ce code
de direction alors que le reste ne changera pas... je ne vois que des
inconvénients à se créer une dépendance sur quelque chose qu'on n'utilise
pas, qui n'a pas de rapport avec le sujet et qui peut changer sans prévenir.

Même choix fait par l'AITF pour le format d'échange des Bases Adresses
Locales, et du coup la clé d'interopérabilité qui se trouve aussi dans les
fichiers BAN.


Le jeu. 12 déc. 2019 à 22:14, Vincent de Château-Thierry 
a écrit :

> Bonsoir,
>
> Le 11/12/2019 à 21:53, deuzeffe a écrit :
> > Le 11/12/2019 à 05:10, Jérôme Amagat a écrit :
> >> Bonjour,
> >>
> >> D’après le wiki il faut 10 caractère dans ref:FR:FANTOIR=*
> >> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR
> >> Il y a beaucoup de valeurs pour ce tag qui compte 11 caractères :
> >> https://overpass-turbo.eu/s/OSX
> >
> > D'après la description du fichier FANTOIR
> > (
> https://www.data.gouv.fr/fr/datasets/r/7c52d813-1e98-4772-8a7a-6a01f9d30c6e
> > ) c'est 11. Sauf que le code direction - fiscale ? - (deuxième "champ")
> > semble avoir été ràz, donc ignoré dans la version finale ?
> >
> > Si quelqu'un y voit plus clair que moi...
>
> Disons que dans OSM depuis au moins le début de BANO (mi 214) on a
> choisi de ne pas considérer ce code direction pour composer ce qu'on
> appelle le ref:FR:FANTOIR. C'est devenu "notre" convention, massivement
> appliquée depuis, et assez pratique puisqu'elle permet très simplement
> un lien avec la commune, vu que les 5 1ères positions du code
> correspondent au code INSEE communal. Je ne sais pas quel avantage /
> quelle interopérabilité nous apporterait l'inclusion du code direction
> en 3è position, je sais en revanche qu'il nous casserait bien les pieds
> à chaque tentative de rapprochement simple entre le code ref:FR:FANTOIR
> et sa commune d'appartenance. On passerait notre temps à détricoter le
> ref:FR:FANTOIR pour en virer le code direction. Un peu pénible...
>
> vincent
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


Re: [Talk-de] ÖPNV Routen Husum (Nordsee)

2019-12-14 Per discussione Michael Reichert
Hallo,

Am 14/12/2019 um 11.48 schrieb goegeo:
> Hallo zusammen, in Husum (Nordsee) wurde am 1. August ein vollkommen
> neues Stadtbusnetz (Website: www.husumbus.de) eingeführt (geänderte
> Routenführung und halb-/stündliche Taktung. Ich habe einige der neuen
> Linienverkehre bereits mit erfasst – allerdings sind auch noch die
> Altlinien noch erfasst (verschiedenene 105x). Geht das in Ordnung, wenn
> ich die historischen Routenrelationen (Altlinien) einfach lösche? Oder
> sollte so etwas auch über das Forum angekündigt/vorher diskutiert
> werden? An dieser Stelle mache ich es ja jetzt schon? Hat jemand hier
> Einwendungen

Wenn die Linien ab morgen nicht mehr verkehren, kannst du ihre
Routenrelationen ersatzlos löschen. OSM ist kein Projekt für historische
Daten. Anders als bei stillgelegten Gleisen bleibt nicht mal mehr ein
naturnahes Biotop zurück.

Bitte denk daran, auch Bushaltestellen, die nicht mehr bedient werden,
zu löschen, wenn sie abgebaut worden sind.

Viele Grüße

Michael



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


Re: [OSM-talk-fr] ref:FR:FANTOIR

2019-12-14 Per discussione Philippe Verdy
Pourra t c'est simple même avec ID d'ajouter la couche BANO et zolmer assez
pour voir les bons codes. Les erreurs fréquentes sont des redoublement de
chiffres, des zéros en plus ou en moins, parfois un code court modifié pour
insérer un code commune mais suivi d'un autre caractère parasite, parfois
un caractère ajouté dans une fausse manip en voulant modifier un autre
tague dans le mauvais champ, et des fausses manips pas toujours visibles à
l'écran quand il y a du lag de l'éditeur ou du navigateur. Ça peut arriver
à tout le monde, mais ce tag franco-français n'a aucune vérif dans les
éditeurs qui laissent passer des modifs pas toujours facile à voir quand on
a voulu modifier tout autre chose, car ça ne se voit pas dans le résumé des
éléments qui seront envoyés.
Ceci dit une requête simple d'un outil de qualité ou une requête sur carte
repéré la plupart des erreurs les plus grossières, les autres sont moins
évidentes mais sont plus rarement des fausses manips, mais ça arrive comme
l'inversion de deux chiffres.

Et c'est la que le code complet a 11 caractères et non 10 (code
département+direction à 3 chiffres et code commune partout à 3 chiffres
même dans les DOM, et non le code INSEE de commune à 5 chiffres) prend son
sens, car la dernière lettre est une clé de vérification calculable qui
permet de détecter les autres codes faux.

C'est facile d'ajouter un code direction 0 pour tous les département sauf
les dom qui  n'ont pas ce code mais utilise un zer de plus au code commune
à deux chiffres. Mais pas si simple à Paris (4 possibilités, aucune à 0),
ou dans les Hauts de Seine, le Nord et les Bouches du Rhône (2
possibilités, aucune à 0, mais deductible de la commune). Ceci fait, on a
10 chiffres où 6 chiffres, 1 lettre et 3 chiffres et la lettre-ce à la fin
qui doit être juste. Une verif automatique est donc simple. Osmose pourrait
faire ces déductions et ameliorer les propositions de correction facilement
mêle sans regarder forcément le nom de rue ou sa localisation précise (qui
peut cependant servir pour vérifier qu'elle proposition de correction est
la plus probable, comme le fait un humain devant l'éditeur ID ou Josm et la
couche BANO chargée au dessus du fond de carte)
Avoir réduit les codes FANTOIR de 11 à 10 caractères en réduisant les codes
commune complets de 6 à 5 chiffres n'a pas aidé beaucoup, eh on note que
les erreurs de code les plus nombreuses sont justement dans les 4
départements où le code direction est non nul et pas unique non plus.

Le sam. 14 déc. 2019 à 10:13, Yves P.  a écrit :

>
>- ref:fantoir et ref:FR:fantoir doivent être renommés en ref:FR:FANTOIR
>- ref:FR:FANTOIR_1 et ref:FR:FANTOIR:2 doivent être supprimé après
>avoir rajouté les valeurs dans ref:FR:FANTOIR
>- ref:right:FR:FANTOIR doit être renommé en ref:FR:FANTOIR:right
>
> J’ai téléchargé et fusionné les valeurs de taginfo.
>
> Avec l’expression rationelle, je trouve 269 061 bonnes valeurs sur 277
> 776. Il y a donc 8 715 valeurs à nettoyer.
>
> Pour les valeurs multiples, j’en trouve :
>
>- 265 à 2
>- 7  à 3 (comme 75120P017N;75111P018D;75111P017C)
>
>
> Il y a 4 392 valeurs trop courtes :
>
>- 0003
>- 0010;0023
>- Z057
>
> 246 valeurs trop longues :
>
>- 01009B005V019K
>
> Des erreurs de copier/coller ?
>
>- 850478210Tno
>- 87076B036Gpond
>
>
>-  102110420G
>-  501730935B
>-  740050009X
>- (132109457B
>- (810040368U
>- (810040770F
>- (810970021M
>- (812180063G
>
>
>
>- 0
>- ?
>- ?
>- unknow yet
>- way 233354872
>- way 353520968
>- way 76663911
>- xxx
>-
>- Place des Tilleuls
>- Q4721000
>- R591831130T
>- R591832098V
>- R591832145W
>- Rue de la Fontaine des Pradels
>- Rue du Vieux Château
>- Rue Haute
>- shelter
>-
>- dd
>- fixeme
>- fixme
>- Impasse de la Source
>- K0236900
>- Le Hameau de la Vigne
>- Le Pont de l'Angle
>-
>- Chemin de Jouanicon
>- Chemin de la Glaine
>- Chemin des Haies
>-
>- BRIQUETERIE
>-
>- associatedStreet
>
>
> —
> 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-in] Reg: OSM India conference

2019-12-14 Per discussione satyakam goswami
On Sat, Dec 14, 2019 at 1:21 PM Asish Abraham Joseph <
asishabrahamjos...@gmail.com> wrote:

> Hey all,
>
> Greetings from Kerala. In light of discussion we had at SotM Asia 2019,
> Saikat Maiti mentioned why shouldn't we host an annual OSM conference in
> India. I wish to know your opinions on starting an OSM India conference.
>

I on behalf of Afrost.org and also an individual is of opinion that we
would be more than happy to help in anyway for hosting the Conference.
Over the decades working in communities and organizing events the initial
core teams is important lets start forming one other things like venue
,sponsor and other logistics can be looked into later on.

thanks
-Satya
Satyakam.dev | afrost.org | fossevents.in 
** For all official purposes use my name as Satyakam Goswami **
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in


[Talk-de] ÖPNV Routen Husum (Nordsee)

2019-12-14 Per discussione goegeo

Hallo zusammen, in Husum (Nordsee) wurde am 1. August ein vollkommen
neues Stadtbusnetz (Website: www.husumbus.de) eingeführt (geänderte
Routenführung und halb-/stündliche Taktung. Ich habe einige der neuen
Linienverkehre bereits mit erfasst – allerdings sind auch noch die
Altlinien noch erfasst (verschiedenene 105x). Geht das in Ordnung, wenn
ich die historischen Routenrelationen (Altlinien) einfach lösche? Oder
sollte so etwas auch über das Forum angekündigt/vorher diskutiert
werden? An dieser Stelle mache ich es ja jetzt schon? Hat jemand hier
Einwendungen

Grüßé, goegeo

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


Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

2019-12-14 Per discussione deuzeffe

Le 13/12/2019 à 18:13, Quentin Salles a écrit :

Bonsoir,


Bonjour,

@deauzeffe Ce que tu dis est juste dans le cas où je cherche les arrêts 
de bus pour une ligne donnée.
Or dans ce que je disais, ça concernait l'ensemble des arrêts desservis 
par toutes les lignes du réseau Tisséo


Rassure-moi : les arrêts en question sont bien dans une relation (avec 
les voies) ie un trajet, elle-même dans la relation globale qui regroupe 
tous les trajets ?


Pour ce que j'ai fait pour le réseau STCLM, j'avoue avoir été fainéante 
et *ne pas avoir* taggué les références sur tous les arrêts.
Ça peut se faire, c'est juste que même si c'est une "petite" CU, il y en 
a whamille. Sans compter qu'il y a des arrêts desservis par plusieurs 
réseau, et que oui, j'ai loupé cette étape. D'où ma préférence pour les 
relations.


--
deuzeffe - partisane de l'effort optimal


Quentin SALLES

Le ven. 13 déc. 2019 à 17:55, laurent-38 > a écrit :


Frédéric Rodrigo-2 wrote
 > Le principe des règles, c'est de corrigé les données, pas les règles.
 > La règle est valide et basé sur le wiki OSM.
 >
 > Le 10/12/2019 à 14:48, Quentin Salles a écrit :
 >> …
 >> Aujourd'hui, Osmose
 >> signale tous les arrêts de bus ayant un mauvais suffixe
d'attribut sur
 >> la clé "ref:FR:Tisséo".

Bonjour Frédéric,

Peux-tu préciser le sens de ta réponse ?

S’agit-il de supprimer les accents dans les clés tels que
ref:FR:Tisséo (ou
ref:Transisère) ? Le wiki ne me semble pas l’interdire :
https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Characters

Ou bien s’agit-il d’enregistrer ces clés dans une « liste blanche »,
type

https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales,
pour qu’elles soient considérées comme correctes ?

Cordialement
~~
laurent



--
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


___
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] ref:FR:FANTOIR

2019-12-14 Per discussione Yves P.
> ref:fantoir et ref:FR:fantoir doivent être renommés en ref:FR:FANTOIR
> ref:FR:FANTOIR_1 et ref:FR:FANTOIR:2 doivent être supprimé après avoir 
> rajouté les valeurs dans ref:FR:FANTOIR
> ref:right:FR:FANTOIR doit être renommé en ref:FR:FANTOIR:right
J’ai téléchargé et fusionné les valeurs de taginfo.

Avec l’expression rationelle, je trouve 269 061 bonnes valeurs sur 277 776. Il 
y a donc 8 715 valeurs à nettoyer.

Pour les valeurs multiples, j’en trouve :
265 à 2
7  à 3 (comme 75120P017N;75111P018D;75111P017C)

Il y a 4 392 valeurs trop courtes :
0003
0010;0023
Z057
246 valeurs trop longues :
01009B005V019K
Des erreurs de copier/coller ?
850478210Tno
87076B036Gpond
 102110420G
 501730935B
 740050009X 
(132109457B
(810040368U
(810040770F
(810970021M
(812180063G

0
?
?
unknow yet
way 233354872
way 353520968
way 76663911
xxx
Place des Tilleuls
Q4721000
R591831130T
R591832098V
R591832145W
Rue de la Fontaine des Pradels
Rue du Vieux Château
Rue Haute
shelter
dd
fixeme
fixme
Impasse de la Source
K0236900
Le Hameau de la Vigne
Le Pont de l'Angle
Chemin de Jouanicon
Chemin de la Glaine
Chemin des Haies
BRIQUETERIE
associatedStreet

—
Yves

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


Re: [talk-cz] Promítnutí změn v OSM nebo chyba editace?

2019-12-14 Per discussione Vaclav Kroupar
Tez mam zkusenost, ze osmap.cz drzi dlouho cache. Pokud nepomuze Ctrl+R, tak 
pri zavrene strance odstranit docasne soubory nebo pouzit jiny prohlizec. 

Vasek

> 14. 12. 2019 v 0:30, Marián Kyral :
> 
> 
> Ahoj,
> na https://hiking.waymarkedtrails.org/#?map=16!50.4123!16.3362 to vidím 
> myslím správně. Buď se to aktualizovalo dnes, nebo máš v keši prohlížeče 
> starší verzi dlaždic na osmap.cz. Zkus vynutit refresh přes Ctrl+R.
> 
> To, že to ještě není na seznamu nemusí nic znamenat. Jejich proces 
> aktualizace je složitější (správné napojení na jejich CZ/SK data)  a vyžaduje 
> více času, takže neaktualizují denně. Klidně to může trvat i měsíc.
> 
> Marián
> -- Původní e-mail --
> Od: Radek Papež 
> Komu: talk-cz@openstreetmap.org
> Datum: 13. 12. 2019 21:01:52
> Předmět: [talk-cz] Promítnutí změn v OSM nebo chyba editace?
> 
> Zdravím,
> 
> před třemi týdny jsem provedl úpravu vedení turistické trasy v polském 
> příhraničí, červená trasa ve skutečnosti totiž vede přímo přes vrchol Grodczyn
> sada změn zde: https://www.openstreetmap.org/changeset/77389905 
> 
> Zajímalo by mne, zda jsem v něčem neudělal chybu, neboť na OSM.cz ve vrstvě 
> „Cyklo+Turistická (EU)“ červená trasa stále vede okolo vrcholu, jakoby žádná 
> úprava neproběhla:
> https://openstreetmap.cz/#map=16/50.4139/16.3321=m 
> 
> Podobně je to na Mapy.cz, které v zahraničí přebírají mapy z OSM, taktéž beze 
> změny:
> https://mapy.cz/s/derupuhute 
> 
> Je potřeba ještě něco udělat, nebo stačí jen vyčkat (a jak dlouho) na 
> aktualizaci mapových dlaždic?
> 
> Díky
> Radek
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [OSM-talk-fr] ref:FR:FANTOIR

2019-12-14 Per discussione Yves P.

> J'ai mis l'expression régulière utilisée, là : 
> https://wiki.openstreetmap.org/wiki/Item:Q600 
> J’ai regardé très rapidement. 
> Elle est assez compliquée 
J’y reviendrais dans un autre mél après quelques tests.

Après un passage sur taginfo 
, je constate qu’il y a du 
nettoyage à faire dans les clés :

QuantitéClé
371304  ref:FR:FANTOIR
6391ref:FR:fantoir
2864source:ref:FR:FANTOIR
261 ref:FR:FANTOIR:left
239 ref:FR:FANTOIR:right
54  source:ref:FANTOIR
22  old_ref:FR:FANTOIR
5   ref:FR:FANTOIR_1
4   ref:fantoir
3   ref:right:FR:FANTOIR
2   name:FANTOIR
1   ref:FR:FANTOIR:2

ref:fantoir et ref:FR:fantoir doivent être renommés en ref:FR:FANTOIR
ref:FR:FANTOIR_1 et ref:FR:FANTOIR:2 doivent être supprimé après avoir rajouté 
les valeurs dans ref:FR:FANTOIR
ref:right:FR:FANTOIR doit être renommé en ref:FR:FANTOIR:right
Je ne vois pas l’intérêt de garder 2 name:FANTOIR 

source:ref:FANTOIR doit être renommé en source:ref:FR:FANTOIR. Y-a-t-il un 
intérêt à cette valeur ? La source de FANTOIR, c’est Bano à 99,99% d’après 
TagInfo  ?

> Jérôme tu as hélas raison mais il y a quand même eu du ménage de fait.
> Xavier essaye :
> https://overpass-turbo.eu/s/OXF 

@Jérôme et @Jean-Yvon : Vos requêtes oublient les clés ref:FR:FANTOIR:left et 
ef:FR:FANTOIR:right
(Ok, moins de mille et aussi les ~6500 ref:FR:fantoir qui devraient être 
fusionnées)

—
Yves


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


Re: [OSM-talk-fr] ref:FR:FANTOIR

2019-12-14 Per discussione osm . sanspourriel
Jérôme tu as hélas raison mais il y a quand même eu du ménage de fait.
Xavier essaye :
https://overpass-turbo.eu/s/OXF
L'autre requête travaillait sur le monde entier.
Jean-Yvon 


> Gesendet: Samstag, 14. Dezember 2019 um 09:05 Uhr
> Von: "XavierBizot22440 - xavierbizot22...@gmail.com" 
> 
> An: "Discussions sur OSM en français" 
> Betreff: Re: [OSM-talk-fr] ref:FR:FANTOIR
>
> C’est quoi le bon zoom pour avoir la requête, parce que moi elle renvoie plus 
> de 100Mo et plante le navigateur
> 
> Merci
> 
> > Le 14 déc. 2019 à 01:47, Jérôme Amagat  a écrit :
> > 
> > 
> > 
> > 
> > Le sam. 14 déc. 2019 à 01:38, Jérôme Amagat  > > a écrit :
> > 
> > 
> > Le ven. 13 déc. 2019 à 22:55,  > > a écrit :
> > Et d'autres ont été actifs ailleurs : actuellement toutes les clés sont à 
> > 11 chiffres (ou 11, un point-virgule et 11).
> > 
> > Tu te trompes, il en reste plein, tu n'as pas modifié la bonne requête, ça 
> > donne ça :
> > https://overpass-turbo.eu/s/OXy 
> > 
> > et même plus précis :
> > https://overpass-turbo.eu/s/OXB 
> > 
> > J'ai mis l'expression régulière utilisée, là : 
> > https://wiki.openstreetmap.org/wiki/Item:Q600 
> > 
> > et j'ai ajouté une phrase sur le wiki dès le début de la page pour dire 
> > qu'il faut 10 caractères : 
> > https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR 
> > ___
> > 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] ref:FR:FANTOIR

2019-12-14 Per discussione XavierBizot22440
C’est quoi le bon zoom pour avoir la requête, parce que moi elle renvoie plus 
de 100Mo et plante le navigateur

Merci

> Le 14 déc. 2019 à 01:47, Jérôme Amagat  a écrit :
> 
> 
> 
> 
> Le sam. 14 déc. 2019 à 01:38, Jérôme Amagat  > a écrit :
> 
> 
> Le ven. 13 déc. 2019 à 22:55,  > a écrit :
> Et d'autres ont été actifs ailleurs : actuellement toutes les clés sont à 11 
> chiffres (ou 11, un point-virgule et 11).
> 
> Tu te trompes, il en reste plein, tu n'as pas modifié la bonne requête, ça 
> donne ça :
> https://overpass-turbo.eu/s/OXy 
> 
> et même plus précis :
> https://overpass-turbo.eu/s/OXB 
> 
> J'ai mis l'expression régulière utilisée, là : 
> https://wiki.openstreetmap.org/wiki/Item:Q600 
> 
> et j'ai ajouté une phrase sur le wiki dès le début de la page pour dire qu'il 
> faut 10 caractères : 
> https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:FANTOIR 
> ___
> 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