Re: [OSM-talk] Crimea situation - on the ground

[Johnparis]

I made such a proposal a while ago; it got majority approval but not the
supermajority required. At the time, I said I don't think a supermajority
is possible. However, my original proposal would, I believe, lend
considerable strength to the OTG rule, especially in hot spots like Crimea.

https://wiki.openstreetmap.org/wiki/Proposed_features/Mapping_disputed_boundaries

On Fri, Feb 7, 2020 at 8:02 PM Mikel Maron  wrote:

> There's two different concepts at play, that OSM does not currently tag
> well when in conflict. There's national sovereignty, which is a political
> concept which in large part depends on international recognition. And
> there's de facto control, which could result from military actions. For
> most of the world, these two are in sync. In Crimea, they are not, and
> there is a dispute.
>
> There are so many varieties of disputed territories in the world, it's
> hard to come up with a system that works for every single situation. And
> tagging structures for disputes could certainly get complicated. However, I
> believe that the OSM community could come up with something that works well
> enough for Crimea, that it would be broadly agreed that the situation is
> represented accurately.
>
> That tagging may not work for every single dispute in the world, but the
> tags could evolve as well as they are implemented in practice.
>
> -Mikel
>
>
>
> On Friday, February 7, 2020, 01:38:23 PM EST, Tomas Straupis <
> tomasstrau...@gmail.com> wrote:
>
>
> Note, that I'm opposing OTG rule application to non-physical objects
> as that is philosophically impossible as well as too unpracticall.
>
>
> ___
> 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: [OSM-talk] bus stop

[Johnparis]

If the bus route does not have fixed stops, it is a hail-and-ride route,
not a fixed-stop route. Public Transport v2 takes both possibilities into
account.

The route relation should include all the road segments involved, and the
relevant segments should have the role:
hail_and_ride

See https://wiki.openstreetmap.org/wiki/Proposed_features/hail_and_ride

As to the name vs number, the agreed naming convention is pretty clearly
spelled out in PTv2. Usually something like this:

For the route master ... Bus 2: City Hall <-> Library (or you can use <=>
or ↔)
For one variant ... Bus 2: City Hall -> Library (or you can use => or →)
For another variant ... Bus 2: Library -> City Hall

etc.

I have ridden buses in many US cities (although never a hail-and-ride) and
they fit nicely into this format.

The line number itself goes in the ref tag in the route relation.





On Fri, Sep 20, 2019 at 5:03 PM john whelan  wrote:

> I'm not sure this is quite the place for this discussion but Europe also
> has some bus routes that pick up and drop off on request.  Just don't map
> none existent stops.
>
> Ottawa Canada has fixed stops as do many other locations in North America.
>
> I suggest you try to map following the wiki map features.  If someone is
> changing your tags then discuss the matter with them as is the traditional
> way to resolve the problem.
>
> Cheerio John
>
> On Fri, Sep 20, 2019, 10:46 AM 80hnhtv4agou--- via talk, <
> talk@openstreetmap.org> wrote:
>
>> europe vs. united states,
>>
>> https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform
>>
>> 1. does not match the way we catch the bus in the usa and the fields are
>> to strict.
>>
>> 2. is a place where i will stand to catch the bus, sign or no sign etc.
>>
>> 3. the map point reflects the area and stops are not set in stone but is
>> based on a driver etc.
>>
>> 4. bus stops are numbered routes as on the sign, the fields do not
>> reflect or allow for this, just the name,
>>
>> the standard web edit map reflects points not route lines, google puts in
>> a no. not a line.
>>
>> looking at a map numbers are more important than names and not all stops
>> have names like
>>
>> someone's driveway.
>>
>>
>> ___
>> 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: [OSM-talk-fr] Géocodage inverse d'un csv avec https://adresse.data.gouv.fr/api

[Johnparis]

C'est fait. Merci de vérifier.

On Sat, Jun 8, 2019, 23:12 Johnparis  wrote:

> Tu as raison. Je vais demander un changement.
>
> On Sat, Jun 8, 2019, 22:15 marc marc  wrote:
>
>> Le 08.06.19 à 10:00, Johnparis a écrit :
>> > quelle est l'erreur de documentation ?
>>
>> je pensais aux 7 exemples avec &
>> Si tu fais un copier/coller, cela ne va pas.
>> il faut une simple/double quotte autour de ce genre d'url
>> ___
>> 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] Proposed mechanical edit - remove blatant duplicates (sustenance=fast_food on amenity=fast_food, atm=yes on amenity=atm etc.)

[Johnparis]

For ATMs, at least, I would propose the opposite: add the atm=yes tag to
all amenity=atm

>From a user perspective, I want to be able to search for atm=yes to obtain
all the nearby ATMs. Removing this tag leaves me without standalone ATMs,
so I would have to search for atm=yes OR amenity=atm

Thus, I don't think this is duplicated information -- it is additional
information. If this were 1965 and we needed to fit everything into 32K of
memory, I'd say fine, but I don't see the need or the advantage.

John


On Fri, Jun 14, 2019 at 9:00 AM Mateusz Konieczny 
wrote:

> Recently in mapping I encountered amenity=atm with atm=yes
>
> I manually removed atm=yes, but it turns that there is more of such
> objects.
> I propose to run an automatic edit that will remove atm=yes from all such
> objects.
> In addition I propose to remove also some other blatant and unnecessary
> duplicates.
>
> So in total I propose to remove
>
> atm=yes from amenity=atm http://overpass-turbo.eu/s/JW8
> transportation=fuel from amenity=fuel http://overpass-turbo.eu/s/JWe
> sustenance=restaurant from amenity=restaurant
> http://overpass-turbo.eu/s/JWh
> sustenance=fast_food from amenity=fast_food http://overpass-turbo.eu/s/JWc
> service=post_office from amenity=post_office
> http://overpass-turbo.eu/s/JWa
>
> as this duplicated tags are unnecessary, unwanted, confusing and
> undesirable.
> Edits would be split to not create overly large bounding boxes.
> ___
> 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] Géocodage inverse d'un csv avec https://adresse.data.gouv.fr/api

[Johnparis]

Tu as raison. Je vais demander un changement.

On Sat, Jun 8, 2019, 22:15 marc marc  wrote:

> Le 08.06.19 à 10:00, Johnparis a écrit :
> > quelle est l'erreur de documentation ?
>
> je pensais aux 7 exemples avec &
> Si tu fais un copier/coller, cela ne va pas.
> il faut une simple/double quotte autour de ce genre d'url
> ___
> 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] Géocodage inverse d'un csv avec https://adresse.data.gouv.fr/api

[Johnparis]

J'ai fait le Pull Request.

On Sat, Jun 8, 2019 at 6:38 PM Johnparis  wrote:

> Je ne pense pas que l'on peut lire les données d'un URL, alors le deuxième
> format est incorrect.
>
> Essayez-le :
>
> curl "http://URL/of/online/file.csv; | curl -X POST -F data=@-
> https://api-adresse.data.gouv.fr/reverse/csv/
>
> par exemple, ça marche :
>
> curl "
> https://overpass-api.de/api/interpreter?data=%5Bout%3Acsv%28%3A%3Alat%2C%3A%3Alon%2Cname%29%5D%5Btimeout%3A25%5D%3B%0Aarea%283600051856%29-%3E.searchArea%3B%0A%28%0A%20%20node%5B%22school%3AFR%22%3D%22maternelle%22%5D%28area.searchArea%29%3B%0A%20%20way%5B%22school%3AFR%22%3D%22maternelle%22%5D%28area.searchArea%29%3B%0A%20%20%29%3B%0Aout%20geom%3B;
> |sed '1 s/@//g'|curl -X POST -F data=@-
> https://api-adresse.data.gouv.fr/reverse/csv/ >output.csv
>
> Notes :
>
> 1) le URL derive de https://overpass-turbo.eu/s/JKu ... cliquez sur
> "Export" puis "raw data directly from Overpass API
> <https://overpass-api.de/api/interpreter?data=%5Bout%3Acsv%28%3A%3Alat%2C%22lat%22%2C%3A%3Alon%2C%22lon%22%2Cname%29%5D%5Btimeout%3A25%5D%3B%0Aarea%283600051856%29-%3E.searchArea%3B%0A%28%0A%20%20node%5B%22school%3AFR%22%3D%22maternelle%22%5D%28area.searchArea%29%3B%0A%20%20way%5B%22school%3AFR%22%3D%22maternelle%22%5D%28area.searchArea%29%3B%0A%20%20%29%3B%0Aout%20geom%3B>"
> pour obtenir le bon URL
> 2) le "sed '1 s/@//g' change @lat->lat et @lon->lon
> 3) le "data=@-" est le syntaxe pour utiliser stdin -- arrobase et tiret
> 4) le ">output.csv" met les resultats dans ce fichier
>
> Cordialement,
>
> John
>
>
>
>
> On Sat, Jun 8, 2019 at 5:01 PM Yves P.  wrote:
>
>>
>> pour information, c'est curl qui exige l'arrobase pour indiquer un
>>> fichier, pas les données eux-meme.
>>>
>>
>> *"If you start the data with the letter @, the rest should be a file name
>> to read the data from, or - if you want curl to read the data from stdin."*
>> (Source: doc <https://curl.haxx.se/docs/manpage.html>)
>>
>> Marc, je peux faire le Pull Request, mais quelle est l'erreur de
>>> documentation ? Il déjà précise l'utilisation de "lat" et "lon", et
>>> l'arrobase.
>>> Peut-etre mieux s'ils donnent un exemple ?
>>>
>>
>> On pourrait mettre en ligne un exemple avec un fichier... en ligne 
>> curl -X POST -F data=@path/to/local/file.csv
>> https://api-adresse.data.gouv.fr/reverse/csv/
>> curl -X POST -F data=URL/to/on-line/file.csv
>> https://api-adresse.data.gouv.fr/reverse/csv/
>>
>> Avec bien sûr, pour le second exemple un lien sur un fichier CSV valide
>> (en ligne sur le site https://adresse.data.gouv.fr/api)
>>
>> __
>> 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-fr] Géocodage inverse d'un csv avec https://adresse.data.gouv.fr/api

[Johnparis]

Je ne pense pas que l'on peut lire les données d'un URL, alors le deuxième
format est incorrect.

Essayez-le :

curl "http://URL/of/online/file.csv; | curl -X POST -F data=@-
https://api-adresse.data.gouv.fr/reverse/csv/

par exemple, ça marche :

curl "
https://overpass-api.de/api/interpreter?data=%5Bout%3Acsv%28%3A%3Alat%2C%3A%3Alon%2Cname%29%5D%5Btimeout%3A25%5D%3B%0Aarea%283600051856%29-%3E.searchArea%3B%0A%28%0A%20%20node%5B%22school%3AFR%22%3D%22maternelle%22%5D%28area.searchArea%29%3B%0A%20%20way%5B%22school%3AFR%22%3D%22maternelle%22%5D%28area.searchArea%29%3B%0A%20%20%29%3B%0Aout%20geom%3B;
|sed '1 s/@//g'|curl -X POST -F data=@-
https://api-adresse.data.gouv.fr/reverse/csv/ >output.csv

Notes :

1) le URL derive de https://overpass-turbo.eu/s/JKu ... cliquez sur
"Export" puis "raw data directly from Overpass API
"
pour obtenir le bon URL
2) le "sed '1 s/@//g' change @lat->lat et @lon->lon
3) le "data=@-" est le syntaxe pour utiliser stdin -- arrobase et tiret
4) le ">output.csv" met les resultats dans ce fichier

Cordialement,

John




On Sat, Jun 8, 2019 at 5:01 PM Yves P.  wrote:

>
> pour information, c'est curl qui exige l'arrobase pour indiquer un
>> fichier, pas les données eux-meme.
>>
>
> *"If you start the data with the letter @, the rest should be a file name
> to read the data from, or - if you want curl to read the data from stdin."*
> (Source: doc )
>
> Marc, je peux faire le Pull Request, mais quelle est l'erreur de
>> documentation ? Il déjà précise l'utilisation de "lat" et "lon", et
>> l'arrobase.
>> Peut-etre mieux s'ils donnent un exemple ?
>>
>
> On pourrait mettre en ligne un exemple avec un fichier... en ligne 
> curl -X POST -F data=@path/to/local/file.csv
> https://api-adresse.data.gouv.fr/reverse/csv/
> curl -X POST -F data=URL/to/on-line/file.csv
> https://api-adresse.data.gouv.fr/reverse/csv/
>
> Avec bien sûr, pour le second exemple un lien sur un fichier CSV valide
> (en ligne sur le site https://adresse.data.gouv.fr/api)
>
> __
> 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-fr] Géocodage inverse d'un csv avec https://adresse.data.gouv.fr/api

[Johnparis]

Merci, Christian.

Marc, je peux faire le Pull Request, mais quelle est l'erreur de
documentation ? Il déjà précise l'utilisation de "lat" et "lon", et
l'arrobase.

Peut-etre mieux s'ils donnent un exemple ?

John



On Sat, Jun 8, 2019 at 9:40 AM Christian Quest 
wrote:

> Ou la corriger avec une PR:
> https://github.com/etalab/adresse.data.gouv.fr/blob/master/pages/api.js#L155
>
> Le ven. 7 juin 2019 à 22:44, marc marc  a
> écrit :
>
>> si quelqu'un est motivé pour leur transmettre leurs erreurs de doc :)
>>
>>
>> Le 07.06.19 à 22:06, Johnparis a écrit :
>> > pour information, c'est curl qui exige l'arrobase pour indiquer un
>> > fichier, pas les données eux-meme.
>>
>
> --
> 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] Géocodage inverse d'un csv avec https://adresse.data.gouv.fr/api

[Johnparis]

pour information, c'est curl qui exige l'arrobase pour indiquer un fichier,
pas les données eux-meme.

On Fri, Jun 7, 2019 at 10:03 PM Johnparis  wrote:

> syntaxe :
>
> 1) il faut utilise l'arrobase après "data="
> 2) après avoir changé @lat->lat et @lon->lon dans ecolesmaternelles54.csv,
> il marche. Resultats ci-joints.
>
> curl -X POST -F "data=@ecolesmaternelles54.csv" "
> https://api-adresse.data.gouv.fr/reverse/csv/; > result.csv
>
> On Fri, Jun 7, 2019 at 9:49 PM Romain MEHUT 
> wrote:
>
>> En d'autres termes, le problème vient de
>> https://api-adresse.data.gouv.fr/reverse/csv/ ?
>>
>> Merci.
>>
>> Romain
>>
>> Le ven. 7 juin 2019 à 21:45, marc marc  a
>> écrit :
>>
>>> j'ai pensé à cela aussi mais j'ai testé en supprimant
>>> une décimale à la fois jusqu'à ne plus en avoir, même erreur
>>> $ cat test.csv ; curl -X POST -F data=test.csv
>>> https://api-adresse.data.gouv.fr/reverse/csv/
>>> latitude,longitude
>>> 48.716261,6.491425
>>> <...>Internal Server Error<...>
>>>
>>> la même précision/localisation avec l'api non csv fonctionne
>>> $ curl
>>> "https://api-adresse.data.gouv.fr/reverse/?lon=6.491425=48.716261;
>>> <...>"3 Grande Rue 54370 Athienville">...>
>>>
>>> ceci dit attention à la doc, les exemples de lignes de commandes
>>> sont inventé/non testé : un curl avec une url contenant des & sans ""
>>> ne peux pas fonctionner, c'est ***
>>> ___
>>> 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] Géocodage inverse d'un csv avec https://adresse.data.gouv.fr/api

[Johnparis]

syntaxe :

1) il faut utilise l'arrobase après "data="
2) après avoir changé @lat->lat et @lon->lon dans ecolesmaternelles54.csv,
il marche. Resultats ci-joints.

curl -X POST -F "data=@ecolesmaternelles54.csv" "
https://api-adresse.data.gouv.fr/reverse/csv/; > result.csv

On Fri, Jun 7, 2019 at 9:49 PM Romain MEHUT  wrote:

> En d'autres termes, le problème vient de
> https://api-adresse.data.gouv.fr/reverse/csv/ ?
>
> Merci.
>
> Romain
>
> Le ven. 7 juin 2019 à 21:45, marc marc  a
> écrit :
>
>> j'ai pensé à cela aussi mais j'ai testé en supprimant
>> une décimale à la fois jusqu'à ne plus en avoir, même erreur
>> $ cat test.csv ; curl -X POST -F data=test.csv
>> https://api-adresse.data.gouv.fr/reverse/csv/
>> latitude,longitude
>> 48.716261,6.491425
>> <...>Internal Server Error<...>
>>
>> la même précision/localisation avec l'api non csv fonctionne
>> $ curl
>> "https://api-adresse.data.gouv.fr/reverse/?lon=6.491425=48.716261;
>> <...>"3 Grande Rue 54370 Athienville">...>
>>
>> ceci dit attention à la doc, les exemples de lignes de commandes
>> sont inventé/non testé : un curl avec une url contenant des & sans ""
>> ne peux pas fonctionner, c'est ***
>> ___
>> 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
>
lat	lon	name	result_latitude	result_longitude	result_label	result_distance	result_type	result_id	result_housenumber	result_name	result_street	result_postcode	result_city	result_context	result_citycode
48.7162618	6.4914257	École maternelle	48.716065	6.491573	3 Grande Rue 54370 Athienville	24	housenumber	ADRNIVX_000265847795	3	Grande Rue		54370	Athienville	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54026
48.6703330	6.1468826	École Claude Déruet	48.670355	6.146862	6 Rue Albert 1er 54600 Villers-lès-Nancy	2	housenumber	ADRNIVX_000265904234	6	Rue Albert 1er		54600	Villers-lès-Nancy	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54578
48.6495464	6.1521676	École Gilberte Monne	48.650206	6.152738	6 Rue d'Aquitaine 54500 Vandœuvre-lès-Nancy	84	housenumber	ADRNIVX_000265925289	6	Rue d'Aquitaine		54500	Vandœuvre-lès-Nancy	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54547
48.6470103	6.2075765	École maternelle Victor Hugo	48.646631	6.207651	31 Rue d'Arbois 54180 Heillecourt	42	housenumber	ADRNIVX_000265924331	31	Rue d'Arbois		54180	Heillecourt	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54257
48.6782268	6.1475850	École maternelle Victor Hugo	48.678537	6.14749	9001 CITE PROV CENTRE COM PRO 54520 Laxou	35	housenumber	ADRNIVX_000265895955	9001	CITE PROV CENTRE COM PRO		54520	Laxou	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54304
48.7277223	6.1578988	École maternelle Buffon	48.727747	6.156822	1 BIS Rue de la Papeterie 54250 Champigneulles	78	housenumber	ADRNIVX_002101781579	1 BIS	Rue de la Papeterie		54250	Champigneulles	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54115
48.7005331	6.1712073	École maternelle Alfred Mézières	48.700714	6.17132	9 Allée Saint-Vincent 54000 Nancy	21	housenumber	ADRNIVX_000265868027	9	Allée Saint-Vincent		54000	Nancy	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54395
48.4769376	6.3157490	École maternelle Françoise Dolto	48.476957	6.315667	18 Rue des Écoles 54290 Bayon	6	housenumber	ADRNIVX_000265997372	18	Rue des Écoles		54290	Bayon	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54054
48.5919694	6.1521632	École maternelle	48.591924	6.151569	8 Grande Rue 54850 Méréville	43	housenumber	ADRNIVX_000265967716	8	Grande Rue		54850	Méréville	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54364
48.7055042	6.2043824	École maternelle Pierre et Marie Curie	48.705434	6.203571	16 Rue Jean Rostand 54130 Saint-Max	60	housenumber	ADRNIVX_000265859249	16	Rue Jean Rostand		54130	Saint-Max	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54482
48.7001981	6.1295821	École maternelle Saint-Exupéry	48.700263	6.129862	9100 Rue de la Chiers 54320 Maxéville	21	housenumber	ADRNIVX_002006009785	9100	Rue de la Chiers		54320	Maxéville	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54357
48.6032829	6.1000594	École La Roseraie	48.603532	6.099572	5001 Rue Raymond Gérard 54550 Pont-Saint-Vincent	45	housenumber	ADRNIVX_000265962473	5001	Rue Raymond Gérard		54550	Pont-Saint-Vincent	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54432
48.4993230	6.8940657	École de Salm	48.49947	6.894202	9001 Rue Raymond Poincaré 54540 Badonviller	19	housenumber	ADRNIVX_000265988182	9001	Rue Raymond Poincaré		54540	Badonviller	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54040
48.8406911	6.0670280	École Aux Moines	48.841038	6.066834	34 Place des Moines 54380 Dieulouard	41	housenumber	ADRNIVX_000354945127	34	Place des Moines		54380	Dieulouard	54, Meurthe-et-Moselle, Grand-Est (Lorraine)	54157
48.9011570	6.0382681	École maternelle	48.900893	

[OSM-talk-fr] lignes RATP/Noctilien

[Johnparis]

Bonjour,

On a tracé la route principale et ajouté les arrêts pour toutes les lignes
RATP/Noctilien. Ils attendent la vérification.

Champagne ?

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

Re: [OSM-talk-fr] Modifications des voies de bus rue de Rivoli

[Johnparis]

Oui, Florimond, je suis d'accord avec toi. Je n'ai touché pas les voies de
bus (qui commencent aujourd'hui à rue du Louvre).

Mais j'ai fait des petites réparations aux relations. Tout va bien à mon
avis pour le moment.

Cordialement,

John


On Wed, May 29, 2019 at 3:42 PM Florimond Berthoux <
florimond.berth...@gmail.com> wrote:

> Bonjour,
>
> Je voulais attendre la fin de la création de la piste cyclable sur toutes
> la longueur de Rivoli pour fusionner la voie bus.
> À ce jour il n'y a plus de séparateur bus-voie générale entre le BHV et
> rue du pont neuf, voir les photos de Géovélo
>
> https://www.mapillary.com/app/?lat=48.85983020064=2.344009531388906=18.929498105208474=FmaNk9oc4A1OIulKFnHokA=photo=0.48170685655044154=0.5525876844334191=0.5903566049646831
>
> Le mer. 29 mai 2019 à 12:38, Johnparis  a écrit :
>
>> Je peux le faire. Mais d'abord je note que c'est patman37 qui a ajouté le
>> nœud 368205 à Métro 1 a tort il y a 4 mois.
>>
>> En tout cas je vais essayer de vérifier les faits.
>>
>> John
>>
>> On Wed, May 29, 2019, 12:18 Phyks  wrote:
>>
>>> Bonjour,
>>>
>>> Je viens de voir passer
>>> https://www.openstreetmap.org/changeset/70697665, qui est assez
>>> illisible et touche un grand nombre d'objets sur la rue de Rivoli.
>>> Certaines modifications ont clairement l'air incorrectes (nœud commun
>>> entre le métro et la rue https://www.openstreetmap.org/node/368205 par
>>> exemple), mais il y a probablement des erreurs plus subtiles aussi que
>>> j'ai ratées.
>>>
>>> Quelqu'un avec une bonne connaissance du coin et des schémas de bus
>>> peut-il jeter un œil et faire un commentaire en conséquence ? En
>>> regardant l'historique du contributeur, il a recommencé à contribuer
>>> récemment après une longue pause (un an), et il y a déjà quelques
>>> commentaires sur des changesets précédents, sans réponse :/ à suivre,
>>>
>>> Bonne journée,
>>> --
>>> Phyks
>>>
>>> ___
>>> 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
>>
>
>
> --
> Florimond Berthoux
> ___
> 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] Modifications des voies de bus rue de Rivoli

[Johnparis]

Je peux le faire. Mais d'abord je note que c'est patman37 qui a ajouté le
nœud 368205 à Métro 1 a tort il y a 4 mois.

En tout cas je vais essayer de vérifier les faits.

John

On Wed, May 29, 2019, 12:18 Phyks  wrote:

> Bonjour,
>
> Je viens de voir passer
> https://www.openstreetmap.org/changeset/70697665, qui est assez
> illisible et touche un grand nombre d'objets sur la rue de Rivoli.
> Certaines modifications ont clairement l'air incorrectes (nœud commun
> entre le métro et la rue https://www.openstreetmap.org/node/368205 par
> exemple), mais il y a probablement des erreurs plus subtiles aussi que
> j'ai ratées.
>
> Quelqu'un avec une bonne connaissance du coin et des schémas de bus
> peut-il jeter un œil et faire un commentaire en conséquence ? En
> regardant l'historique du contributeur, il a recommencé à contribuer
> récemment après une longue pause (un an), et il y a déjà quelques
> commentaires sur des changesets précédents, sans réponse :/ à suivre,
>
> Bonne journée,
> --
> Phyks
>
> ___
> 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-transit] Ideas for a simplified public transportation scheme

[Johnparis]

I agree that platforms should be mapped as ways only if they physically
exist. What I'm saying is that I don't object if someone does map such an
object, but the information from the transit agency should always be
contained in a node, not a way, as Jo mentioned.

I usually place the node inside the closed way if it exists, but another
possibility (and necessary if it's an unclosed way) is to make the node a
part of the way.



On Mon, May 13, 2019 at 5:36 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> On 13/05/2019 16:14, Johnparis wrote:
> > I don't have any particular problem with mapping an area (closed way) or
> a
> > way (line segment) as a platform,
>
> Please, please only map a platform /if/ it's a physical structure.
> Imaginary meta-objects  don't work in OSM
>
> DaveF
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Johnparis]

the bus stop (platform) node allows for shelter=yes/no and bench=yes/no, so
it's not really necessary to separately map them and/or group them into the
stop area.


On Mon, May 13, 2019 at 5:30 PM Philip Barnes  wrote:

> On Monday, 13 May 2019, Dave F via Talk-transit wrote:
> >
> >
> > On 13/05/2019 16:14, Philip Barnes wrote:
> > >
> > > I can see that when its raining I may want the router to direct me to
> a stop with a shelter rather than stand in the rain.
> > Surely you need to be given the bus stop which will take you to your
> > destination? That /is/ the point of a router.
> >
> I do, but there tend to be lots of bus stops and sometimes I want it to
> choose the one with the shelter if its only a short extra walk.
>
> Phil (trigpoint)
>
> --
> Sent from my Sailfish device
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Johnparis]

I don't have any particular problem with mapping an area (closed way) or a
way (line segment) as a platform, but I agree with Jo that the information
should be contained in a node. That node can be part of the way. From
experience, it complicates things quite a bit when you transfer the
information from the node to the way.


On Mon, May 13, 2019 at 5:10 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> On 13/05/2019 07:36, Tijmen Stam wrote:
> > On 13-05-19 00:14, Jo wrote:
> >> I like to keep things simple, the best way to accomplish that, is by
> >> having a single object for each stop that holds all the details for
> >> its "lifetime". That's why I don't like the idea of 'upgrading from a
> >> node to a way/area or a relation.
> >
> > I don't agree with you on that point. With that view we can't change
> > things in OSM anymore to a more precise mapping.
>
> A bus stop as a node to represent the sign/pole is /far/ more accurate
> than an arbitrary invisible mutli-noded polygon.
>
> DaveF
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Johnparis]

Definitely not non-transit items.

GTFS defines the equivalent of a stop area. The Paris regional transit
agency largely reflects these as transfer points between lines of different
bus companies. It can also be useful to link a stop position to a platform,
which can be very useful when it's not clear which street the platform is
facing.

A stop area in Paris, for example, might be Gare Saint-Lazare, which would
group (a) the many bus stops (platforms) named "Gare Saint-Lazare" in the
neighborhood, (b) possibly any associated stop positions for those bus
platforms, (c) the metro lines with Gare Saint-Lazare stations, the
platforms of which differ, (d) the regional train lines that terminate at
Gare Saint-Lazare, (e) any intercity trains that go there.

In general I don't use them.

On Mon, May 13, 2019 at 5:03 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

>
>
> On 12/05/2019 23:14, Jo wrote:
> > About the stop_area relations, they're not needed everywhere, but they
> > could be used to show what belongs together. Of course, that would mean
> all
> > the objects related to the stop at one side of the street, not both
> sides.
>
> Why items "belong together"?
> Does a router need to know there's a shelter, benches, litter bind etc?
>
>
> DaveF
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Johnparis]

If a platform is multimodal, highway=bus_stop fails, because the same node
requires (for example) railway=tram_stop



On Mon, May 13, 2019 at 4:56 PM Dave F via Talk-transit <
talk-transit@openstreetmap.org> wrote:

> On 12/05/2019 19:55, Tijmen Stam wrote:
> .
> >
> > No, changing of tagging, not replication.
> > There is no need to map with highway=bus_stop anymore (save for
> > rendering on osm_carto)
>
> No. highway=bus_stop is fully relevant as the day it was first used.
> It's simple, clear, comprehensible meaning far out ways the supposedly
> "overwhelming" PT tagging which few mappers have adopted. This thread
> wouldn't have happened it is was popular. It appears dead in the water.
>
> Show me how p_t=platform adds anything to the quality of the OSM
> database over highway=bus_stop.
>
> DaveF
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk-fr] fee = interval ?

[Johnparis]

Oui, le wiki en anglais precise cela.

fee = yes/no/ (pas le mot "interval", mais les horaires)

Le wiki en anglais precise le mot "interval" en italique. Le wiki en
français a tout les mots "yes/no/interval" en italique.

Recemment il y avait ce commentaire :

I would rather use fee:conditional

=* using conditional restrictions
 syntax - it
keeps value of fee tag usable without extensive processing Mateusz Konieczny
 (talk
) 22:20, 8
February 2018 (UTC)

Moi je suis d'accord avec Mateusz.

On Wed, Apr 24, 2019 at 8:39 PM Leni  wrote:

>
> Je suis d'accord dans "fee="  correspondent bien à
> l'intervalle de temps pendant lequel le parking est payant, mais il faut
> utilisée la même syntaxe que pour les heures d'ouverture.
>
> Leni
> --
> *De:* "Noémie Lehuby via Talk-fr"
> *Envoyé:* Wed Apr 24 19:50:38 GMT+02:00 2019
> *À:* "Discussions sur OSM en français"
> *Cc:* "Noémie Lehuby"
> *Sujet:* [OSM-talk-fr] fee = interval ?
>
> Bonjour,
>
> J'ai remarqué qu'il y avait pas mal d'occurrences de fee = interval sur
> des parkings. Je n'arrive pas trop à comprendre comment interpréter
> cette valeur pour déterminer si le parking est payant ou pas.
>
> J'ai l'impression que ça ne devrait pas exister et que ça vient d'une
> confusion dans le wiki, qui dit :
>
> fee=interval - Le paiement n'est requis qu'à certaines heures de la
> journée, utilisez la même syntaxe que pour opening_hours=*, par exemple
> : fee=Mo-Fr 08:00-13:00
>
> Qu'en pensez-vous ?
>
> nlehuby
>
>
> --
>
> 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] Rencontre des contributeurs parisiens

[Johnparis]

19h encore ?

On Fri, Apr 5, 2019 at 10:03 PM François Lacombe 
wrote:

> Salut à tous,
>
> Voici donc la confirmation de cette invitation à se retrouver à Paris
> mardi 09/04 prochain.
>
> Par un heureux hasard du calendrier, CartONG tient une permanence mardi
> soir dans le 13ième arrondissement, à l'ESS'pace
>
> https://www.openstreetmap.org/?mlat=48.82700=2.38367#map=18/48.82700/2.38367
>
> Nous pourrons donc nous retrouver là-bas et partager quelques verres et
> rencontres avec les membres de CartONG.
>
> Au plaisir de vous y retrouver, passez une bonne soirée et un bon weekend
>
> François
>
> Le lun. 1 avr. 2019 à 00:11, François Lacombe 
> a écrit :
>
>> Salut à tous
>>
>> Vu les résultats du framadate et mon propre emploi du temps, je pense
>> qu'on peut partir sur mardi 09/04
>>
>> Ce qui n'interdit pas de se retrouver plus souvent à d'autres dates,
>> évidemment
>>
>> François
>>
>> Le sam. 23 mars 2019 à 15:08, François Lacombe 
>> a écrit :
>>
>>> Re-bonjour la liste
>>>
>>> Cela fait un petit moment depuis la dernière rencontre que les
>>> contributeurs parisiens (ou les contributeurs de passage à Paris à ce
>>> moment là) ne se sont pas réunis.
>>>
>>> Ce serait une bonne idée d'organiser une nouvelle rencontre avec les
>>> présents dans le courant de la semaine 14, comme beaucoup de groupes locaux
>>> en ont pris l'habitude.
>>> Le principe est assez simple, un lieu convivial, à boire/manger, des
>>> contributeurs pour avoir des discussions intéressantes
>>>
>>> La dernière réunion s'est tenu au Nouvel Institut vers Jussieu, sauf
>>> contraintes je vous propose de se retrouver là-bas.
>>> https://www.openstreetmap.org/node/262934233
>>>
>>> Egalement ce framadate pour choisir une date
>>> https://framadate.org/kzRj1PN1QtpMmZzglmmtTIHw/admin
>>>
>>> Évidemment tout le monde est le bienvenu.
>>>
>>> Bon weekend
>>>
>>>
>>> François
>>>
>> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk] Fwd: Feature Proposal - Voting - Mapping disputed boundaries

[Johnparis]

As promised, I have opened the Mapping Disputed Boundaries proposal for
voting. Voting will be open until Feb. 10.

https://wiki.openstreetmap.org/wiki/Proposed_features/Mapping_disputed_boundaries#Voting

The main discussion has been on the Tagging list: 

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

Re: [OSM-talk] junction=yes

[Johnparis]

It's pretty clear that the intention of this tag is only for junctions that
have a name. It was part of this proposal:

https://wiki.openstreetmap.org/wiki/Named_spots_instead_of_street_names

I think it would be appropriate to add some background to the wiki, and in
particular to clarify the "When not to use" section.

https://wiki.openstreetmap.org/wiki/Tag:junction%3Dyes



On Sat, Jan 26, 2019 at 11:27 PM Jack Armstrong dan...@sprynet.com <
jacknst...@sprynet.com> wrote:

> Some users are adding junction=yes to every intersection, large or small.
> This seems very much incorrect to me. Is there a definitive answer as to
> whether this is correct or not?
>
> https://www.openstreetmap.org/edit#map=19/-0.17531/-78.48083
>
>
>
>
> ___
> 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] Des Orthophotos ne fonctionne de nouveau plus

[Johnparis]

Mauvais lien. Essayez :

https://openstreetmap.assoconnect.com/billetterie/offre/90295-e-renouvellement-de-nos-serveurs

On Fri, Nov 30, 2018, 13:04 lau  Hello Hugo,
>
> je crois que c'est une incitation à faire un don pour atteindre les 5000
> €... qui permettront d'investir dans un nouveau serveur pour les
> orthophotos ;)
>
>
> https://openstreetmap.assoconnect.com/billetteraie/offre/90295-e-renouvellement-de-nos-serveurs
>
> En attendant : @Christian ! Help !?
>
> À bientôt,
>
> Laurence
> Le 29/11/2018 à 17:25, hugobqd...@laposte.net a écrit :
>
> Bonjour,
> j'ai l'impression qu'il y a de nouveaux problèmes de chargement des fonds :
>
>- Tours - Orthophotos 2013 : « GET
>http://wms.openstreetmap.fr/tms/1.0.0/tours_2013/18/131565/91821 500
>(Internal Server Error) »
>- Tours - Orthophoto 2008-2010 : « GET
>http://wms.openstreetmap.fr/tms/1.0.0/tours/14/8223/5738 500 (Internal
>Server Error) »
>- BDOrtho IGN (à partir du zoom 19/20) : « GET
>https://proxy-ign.openstreetmap.fr/94GjiyqD/bdortho/19/263125/183645.jpg 
> 404
>(Not Found) »
>
> Salutations / Hugo
>
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
> --
> Laurence picadolaupic...@posteo.net
> 07 83 15 49 07
>
> ___
> 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] Feature Proposal - RFC - Mapping disputed boundaries

[Johnparis]

Thank you, Victor. In fact, that is what I have done in the case of Spain,
which did not have properly closed land borders, in the example from the
proposal.

On Tue, Nov 27, 2018 at 12:57 PM Victor Shcherb 
wrote:

> Hi All,
> It might sound a bit critical but I believe the ways *without a role * in
> admin_level=2 creates more confusion than bring value.
> First of all, the biggest value of admin_level=2:
> - to identify country as it is in UN
> - to have name translated in different languages
> - to have extra tags related to the country (probably spoken language or
> some details like right/left hand driving)
> - define further administrative structure *driven by local country
> authorities.*
>
> I like the idea that Ukraine has a proper admin subdivision for regions
> defined by local OSM community and it has Crimea registered with role
> "claimed" which is 1) indicative and 2) valuable
>
> Ways on these relations could be misinterpreted  as 1) official boundaries
> by UN 2) boundaries that are controlled and patrolled by official army 3)
> boundaries "recognized" by OSMF 4) boundaries by constitution of the
> country itself . And it creates a mess of interpretation and doesn't help
> anybody.
>
> Another argument that ways of admin_level=2, these enormous relations are
> mostly broken and create issues for editing/validating anyway. In theory
> the users of admin_level boundaries could use the sum of further
> administrative division and subselect proper roles.
>
> So, I would suggest:
> 1) To get rid of non-role member ways from admin_level relation
> 2) But keep the ways themselves visible that will represent controlled
> boundaries
>
> Best Regards,
> Victor
>
> On Tue, 27 Nov 2018 at 09:33, Roland Olbricht 
> wrote:
>
>> Hi all,
>>
>> a much simpler approach is to look into the respective constitution.
>>
>> The Ukrainian constitution defines the state's territory in article 133.
>> Other countries, like Germany do so as well, and Ireland does or has
>> done so. France does not define its terriotry in the constitution, and
>> the UK has AFAIK no constituation. Probably in both countires laws exist.
>>
>> Thus I suggest to create a relation comprising the regions mentioned in
>> that said article. It should hold the various name tags and a distinct
>> tag (not "boundary", "admin_level", or "source") to indicate that it is
>> a boundary according to the consitution, e.g.
>> "legitimation=constitution" (and "legitimation=national_law" if not
>> declared by the constitution). Countries where the constitution
>> conincides with the de-facto border can just get the tag.
>>
>> For Cyprus and Western Sahara, I have been unable to find the relevant
>> documents. I'm cautiously optimistic that they can be modeled in the
>> same way.
>>
>> Given that there is at most one constiution per country, that those are
>> designed to change infrequently and most countries are expected to
>> conincide, this allows to add no-nonsense data without opening a can of
>> worms.
>>
>> Best regards,
>>
>> Roland
>>
>> ___
>> 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] Feature Proposal - RFC - Mapping disputed boundaries

[Johnparis]

Here's a link to this thread on the Tagging list :

https://lists.openstreetmap.org/pipermail/tagging/2018-November/041109.html

And a link to the main Tagging thread that most recently raises this
subject:

https://lists.openstreetmap.org/pipermail/tagging/2018-November/040858.html

And finally a link to the proposal:

https://wiki.openstreetmap.org/wiki/Proposed_features/Mapping_disputed_boundaries


On Tue, Nov 27, 2018 at 3:21 AM Johnparis  wrote:

> A general proposal to address mapping disputed borders at the national
> level.
>
> I've read the discussions on the Tagging and Talk lists, and have given
> the matter considerable thought (and experimented with different
> approaches) before formulating the proposal. I hope it offers a mechanism
> to show boundary claims in addition to the current display of de facto
> boundaries.
>
> John
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Feature Proposal - RFC - Mapping disputed boundaries

[Johnparis]

A general proposal to address mapping disputed borders at the national
level.

I've read the discussions on the Tagging and Talk lists, and have given the
matter considerable thought (and experimented with different approaches)
before formulating the proposal. I hope it offers a mechanism to show
boundary claims in addition to the current display of de facto boundaries.

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

Re: [OSM-talk-fr] Chemin en bois sur pilotis

[Johnparis]

C'est un boardwalk en anglais

https://en.m.wikipedia.org/wiki/Boardwalk

Alors ...

bridge=boardwalk

https://wiki.openstreetmap.org/wiki/Tag:bridge%3Dboardwalk



On Sat, Nov 10, 2018, 12:02 Gwenaël Jouvin  Bonjour à tous,
>
> Récemment j’ai vu dans une forêt, un chemin construit en lattes de bois,
> le tout surélevé d’environ 30 cm à 50 cm au-dessus du sol à l’aide de
> pilotis.
>
> Je ne connais pas le terme technique qui désigne ce genre de chose, alors
> voici une illustration :
>
> https://www.visorando.com/images/original/chemin-sureleve-par-un-platelage-visorando-30127.jpg
>
>
> Actuellement il est taggé
> highway=path
> surface=wood
>
> … ce qui ne transcrit pas la particularité de l’aménagement. On pourrait
> éventuellement y ajouter la largeur.
>
> Cependant, existe-t-il un attribut particulier pour indiquer précisément
> que c’est un platelage surélevé ?
>
>
> Merci.
>
> ___
> 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] Fwd: DWG policy on Crimea

[Johnparis]

This thread has strayed rather far afield from the original question, which
was whether the OSM depiction of Crimea corresponds to the OSMF policy. It
seems clear to me that it does not.

I would suggest that the depiction of Northern Cyprus does not correspond
to the policy either. The actual physical control boundary is depicted at
admin_level 3 or 4 rather than 2.

Cheers,

John

On Tue, Oct 23, 2018 at 1:05 PM Frederik Ramm  wrote:

> Hi,
>
> On 23.10.2018 11:06, Christoph Hormann wrote:
> > I think that would not be verifiable.  Different political fractions
> > often even have different opinions on the extent of their country.  OSM
> > is not a place to record a spectrum of opinions
>
> Agreed. I would be tempted to say, however, that if a country requires a
> certain boundary depiction by law, like e.g. India and China do, then
> that's the same level of verifiability like that country's internal
> boundaries for which we also rely on what the "official" take is. At
> least the current laws regarding the Indian border are much more than
> "an opinion of a political faction".
>
> Having said that - Portugal still officially claims Olivença but it
> seems to be more a folkloristic thing than an actual dispute, and the
> average Portuguese would probably be astonished if a map were to
> actually depict Olivença as part of Portgual. This means we'd have to
> start which claims are serious and which are just for old times' sake ;)
>
> 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
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

[Johnparis]

Bonjour,

Il y a deux discussions mélées dans ce sujet : les routes de substitution
et l'utilité de route_ref.

Je m'adresse d'abord aux lignes.

Moi je pense que la "substitution" applique aux relations, pas aux noeuds
(arrêts). Normalement, le noeud désigne un endroit physique. Si je pense
d'un arrêt de substitution et d'un arrêt "normale", dois-je les fusionner ?
Si oui, le tag "subsitution=yes" a tort, parce que l'arrêt lui-même n'est
pas un arret de subsitution.

Alors, substitution:route_ref est preferable. Mais je pense que
route_ref:substitution=* est meilleur. C'est les routes (et donc les
route_ref) qui sont de substitution, pas les noeuds.

Je ne trace pas les lignes de substitution, mais chacune a son route_ref.
Par exemple, on peut dire pour le StopPoint:76:150 :

name=Gare du Nord Surface
route_ref:substitution=H SSB-PAR

... et pour la relation ...
name=Bus H SSB-PAR : Travaux Sarcelles St Brice - Paris Est
ref=H SSB-PAR
substitution=yes

Si l'on veut indiquer la ligne substituée, on peut ajouter sur la relation :
substitution:route_id=800:H (ou substitution:ref=Train H ou Ligne H)

===

Deuxième chose : les route_ref si la relation existe.

Moi je suis pour les route_ref, après avoir utilisé les deux methodes.

1. Il y a des arrêts où la desserte est secondaire, mais seulement la
relation de la desserte principale existe dans OSM.
2. Cela ameliore la contrôle de la qualité. Si l'on trouve un desaccord
entre la relation et le noeud, Osmose peut signaler un problème.
3. Le problème des données qui ne sont pas perennes existent dans les deux
cas. OSM, comme Wikipedia, est toujours une approximation sujet à
l'amelioration. Mais si les lignes changent, c'est plus facile de savoir si
l'on a le route_ref.
4. Pour le consommateur, c'est plus facile de lire un tag "route_ref" que
construire les relations.
5. Encore pour le consommateur, imaginez un noeud avec
route_ref=1;2;3;4;5;6 qui est dans les relations avec ref=1,2,5,6. (Les
relations 3 et 4 ne sont pas encore construit.) Si vous retirez juste les
"doublons" on trouve route_ref=3;4. Mais si le consommateur regarde le
noeud, et trouve route_ref=3;4, normalement il va penser qu'il n'y a que
deux lignes qui desservent l'arrêt, non ?

Cordialement,

John






On Fri, Oct 12, 2018 at 6:13 PM Florian LAINEZ  wrote:

> Hello,
> Je suis d'accord avec Marc : l'utilisation d'une relation est à terme la
> meilleure manière de faire. Et créer un tag qui devrait être une relation
> est risqué pour la pérennité des données.
> Néanmoins je suis aussi d'accord avec Charles : pour l'instant
> l'utilisation d'un tag est le plus simple.
> substitution:route_ref me parait en effet tout indiqué.
>
> pour moi l'élément clef qui nous pousse à ne pas utiliser les relations à
> ce stade est que l'on ignore 1. les différents arrêts desservis par chaque
> ligne de substitution 2. le trajet de ceux-ci.
> Étant donné que l'on ignore tout des lignes à ce stade, je suis d'avis de
> mapper directement avec des tags sur les arrêts.
>
>
> Le ven. 12 oct. 2018 à 13:40, Charles MILLET  a
> écrit :
>
>> Merci beaucoup pour tes précisions Marc !
>>
>> Je suis globalement d'accord avec tes arguments pour ce qui est de la
>> redondance, j'attends un peu d'avoir à nouveau les explications des
>> "pour" avant d'avoir un avis définitif.
>>
>> Effectivement ce serait assez cohérent d'utiliser substitution:route_ref
>>
>> On 12/10/2018 12:58, marc marc wrote:
>> > Bonjour,
>> >
>> > Le 12. 10. 18 à 11:24, Charles MILLET a écrit :
>> >> Pour résumer tu n'est pas pour parce que tu n'est déjà
>> >> pas pour le route_ref ?
>> > oui en résumé c'est exactement cela. je suis contre subtitution:lines
>> > permanent parce que je suis contre l'utilisation permanente de route_ref
>> >
>> > Si c'est un tag temporaire comme un étape intermédiaire renseignant
>> > les informations destiné à la création des relations, c'est utile
>> > mais autant garder la même logique et créer subtitution:route_ref
>> > Et je passerai à la relation même imparfaite dès que possible.
>> >
>> >> https://wiki.openstreetmap.org/wiki/Key:route_ref et cette remarque :
>> >> [route_ref=* can easily be added to individual bus stops without
>> knowing
>> >> the whole route a service takes. It can serve as a basis to add the
>> full
>> >> route relation LATER on]
>> > je partage cet avis :
>> > route_ref est utile quand il est utilisé temporairement "je suis passé
>> > devant l'arrêt, il désert la ligne 42, je le renseigne pour l'ajouter
>> > PLUTARD à la relation par ex avec un outil + adapté", c'est donc
>> > à mes yeux signe de "ce n'est pas finit, il y a des choses à faire".
>> > (même si je trouve qu'utiliser une clef spécifique pour une note/fixme
>> > dédié aux lignes c'est une mauvaise idée, c'est "une chose de + à
>> > requêter" et si chaque catégorie de donnée utilisait une clef
>> > différente, ce serrait pas génial)
>> >
>> > mais quand il est permanent, c'est une donnée dupliquée avec la galère
>> > que cela 

Re: [OSM-talk] Representing places with no housenumber

[Johnparis]

I would disagree with Christoph's assumption that addresses must be unique.
The purpose of an address is to help someone locate something. It gets
"close enough", with the definition of that phrase varying by
locality/society/observer. ALL addresses, in that sense, are "partial", to
use Christoph's term.

Multiple objects may share an address. In fact, this has just been raised
in the context of cycleways (should they share the name of the street they
parallel?). Other examples have already been given in this thread (the red
shed). And the converse is also true: single objects may have multiple
addresses. Addresses can be many-to-one or one-to-many; a one-to-one
relationship is not required.

Back to the OP, I think the "no" prefix tags are problematic in general
(noaddress, noname). I personally like Martin's proposal of a "no_" prefix.
At least that's easier for data consumers to suss out. So I'd vote for
no_addr:housenumber=yes.

There is, in fact, an address in these cases, so "noaddress=yes" is wrong.

John


On Fri, Aug 24, 2018 at 4:49 PM Warin <61sundow...@gmail.com> wrote:

> On 24/08/18 18:40, Rory McCann wrote:
> > On 22/08/18 23:40, Christoph Hormann wrote:
> >> On Wednesday 22 August 2018, Rory McCann wrote:
>  The single most important property of an address is that it is
>  unique
> >>>
> >>> 35% of addresses in Ireland aren't unique.
> >>
> >> I strongly suspect we have a different understanding of either 'address'
> >> or 'uniqueness' here.
> >
> > Possibly. The Irish definition is "a property has the same address with
> > a least one other property". I'm not talking about 2 postboxes that are
> > beside each other in an apartment block, but 2 houses which could be a
> > distance apart. Post/Packages is delivered partially based on surname,
> > or "local knowledge" . It is/was a pain. The new postcode ("eircode")
> > will help. Now, you may say the surname is part of the address, but what
> > happens when someone moves house?
>
> The 'names' I refer to are the 'names' of the property, not the name of
> the resident/s.
>
>
>
>
> ___
> 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] [OKFILTER] Re: [OKFILTER] Modifier un pont erroné avec une dizaine de relations imbriquées au moins.

[Johnparis]

Evidemment nous avons faites presque la meme chose, Jo.

Alors, Alain, à toi à decider

2018-07-26 20:50 GMT+02:00 Jo :

> C'est envoyé finalement, mais maintenant il y a 2 ponts... pas idéal.
>
> Op do 26 jul. 2018 om 20:49 schreef Jo :
>
>> Zut, j'aurais dû faire ça plus vite au lieu de trainer sur les relations
>> cyclistes et de randonnée. Maintenant j'ai un tas de conflits à resoudre et
>> des décisions plus ou moins impossibles à prendre...
>>
>> pfff, il fait chaud.
>>
>> Jo
>>
>> Op do 26 jul. 2018 om 20:30 schreef Johnparis :
>>
>>> Bonjour,
>>>
>>> J'ai pris la main. Je ne peux pas voir exactement qu'est-ce qui se passe
>>> au milieu de la rivière ; je pense peut-etre il y a une barrière, mais on
>>> peut l'approche des deux côtés. N'hésitez pas à la corriger. (J'ai utilisé
>>> iD.)
>>>
>>> Pour l'autre question (confondre la rivière et les limites
>>> administratives), c'est plutôt commun, malheureusement, je pense, mais je
>>> ne le touche pas.
>>>
>>> Cordialement,
>>>
>>> John
>>>
>>> 2018-07-26 19:27 GMT+02:00 Rpnpif :
>>>
>>>> Bonsoir,
>>>>
>>>> C'est un appel à un ou des experts OSM.
>>>>
>>>> À cet endroit https://www.openstreetmap.org/way/225134301, ce vieux
>>>> pont que je connais depuis toujours est erroné, le dessin s'arrête en
>>>> plein milieu de la rivière au lieu de la traverser.
>>>>
>>>> Id indique qu'il est impossible à prolonger.
>>>> JOSM casse 13 ou 17 relations. J'ai peur de ne pouvoir les restaurer.
>>>>
>>>> L'erreur des contributeurs précédents est aussi d'avoir lié inutilement
>>>> le flux de la rivière au pont et à une multitude de limites
>>>> administratives (régionale, deux départements, plusieurs communes,
>>>> etc.) C'est affreusement complexe.
>>>> Pire, le flux de la rivière a été tagué pour en faire une limite
>>>> administrative ce qui me semble une très mauvaise pratique.
>>>>
>>>> Je suis preneur de toute idée pour modifier ça car je ne vois pas
>>>> comment faire sans y passer des heures ou sans dégâts.
>>>> Faire disparaître les balises water du flux provisoirement et
>>>> redessiner la rivière l'Oust, affluent de la Vilaine ?
>>>>
>>>> Ce serait bien qu'Osmose détecte ce genre de broullimani mais peut-être
>>>> le fait-il déjà.
>>>>
>>>> Au secours donc ;).
>>>>
>>>> Qu'en pensez-vous ? Vous pouvez prendre la main si vous voulez.
>>>>
>>>> --
>>>> Alain Rpnpif
>>>>
>>>> ___
>>>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OKFILTER] Modifier un pont erroné avec une dizaine de relations imbriquées au moins.

[Johnparis]

Bonjour,

J'ai pris la main. Je ne peux pas voir exactement qu'est-ce qui se passe au
milieu de la rivière ; je pense peut-etre il y a une barrière, mais on peut
l'approche des deux côtés. N'hésitez pas à la corriger. (J'ai utilisé iD.)

Pour l'autre question (confondre la rivière et les limites
administratives), c'est plutôt commun, malheureusement, je pense, mais je
ne le touche pas.

Cordialement,

John

2018-07-26 19:27 GMT+02:00 Rpnpif :

> Bonsoir,
>
> C'est un appel à un ou des experts OSM.
>
> À cet endroit https://www.openstreetmap.org/way/225134301, ce vieux
> pont que je connais depuis toujours est erroné, le dessin s'arrête en
> plein milieu de la rivière au lieu de la traverser.
>
> Id indique qu'il est impossible à prolonger.
> JOSM casse 13 ou 17 relations. J'ai peur de ne pouvoir les restaurer.
>
> L'erreur des contributeurs précédents est aussi d'avoir lié inutilement
> le flux de la rivière au pont et à une multitude de limites
> administratives (régionale, deux départements, plusieurs communes,
> etc.) C'est affreusement complexe.
> Pire, le flux de la rivière a été tagué pour en faire une limite
> administrative ce qui me semble une très mauvaise pratique.
>
> Je suis preneur de toute idée pour modifier ça car je ne vois pas
> comment faire sans y passer des heures ou sans dégâts.
> Faire disparaître les balises water du flux provisoirement et
> redessiner la rivière l'Oust, affluent de la Vilaine ?
>
> Ce serait bien qu'Osmose détecte ce genre de broullimani mais peut-être
> le fait-il déjà.
>
> Au secours donc ;).
>
> Qu'en pensez-vous ? Vous pouvez prendre la main si vous voulez.
>
> --
> Alain Rpnpif
>
> ___
> 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] Tagger voie bus/vélo/taxis uniquement?

[Johnparis]

Parce que access=no implique motor_vehicle=no, le motor_vehicle tag n'est
pas nécessaire.

Si la voie de bus n'est pas physiquement separée des autres voies, on peut
utiliser les tags suivants sur la seul way :

oneway=yes
busway:left=opposite_lane
busway:right=lane
cycleway:left=share_busway
cycleway:right=share_busway

Selon Mlle. Google (je ne suis pas là-bas) les voies ne sont pas
physiquement separées (en août 2017), alors way 610465836 (par Shohreh) a
tort et way 27773625 (par Truchin) a raison.





2018-07-24 11:00 GMT+02:00 Shohreh :

> Je m'auto-réponds : il fallait créer une nouvelle way avec les tags
> suivants,
> comme ça existait déjà plus haut sur le boulevard Saint-Michel. Étonnant
> qu'une artère aussi importante en plein Paris ait été oubliée alors qu'elle
> existe depuis longtemps.
>
> highway=service
> access=no
> motor_vehicule=no
> psv=yes ("Public Service Vehicles")
> bicycle=yes
>
>
>
> --
> 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

Re: [Talk-transit] [OKFILTER] [Tagging] Public Transport v3 — starting RFC

[Johnparis]

This is a very long and complex proposal, so it will take me a while to
digest and respond. I am also alerting the transport mailing lists in
English and French. I trust the RFC will be open for at least for a couple
of months.

Cette proposition (en anglais) est très longue et complexe, il me faudra
donc du temps pour digérer et répondre. J'alert également les listes de
diffusion de transport en anglais et en français. J'espère que le RFC sera
ouvert au moins pour quelques mois.

John

On Fri, Jul 20, 2018 at 3:48 PM, Ilya Zverev  wrote:

> Hi folks,
>
> As you might've noticed, in the past year there has been growing
> discomfort with the current Public Transport tagging schema. Of course, it
> brought order to our route relations, but also introduced a lot of
> redundant concepts. We've seen a couple proposals aiming to fix some of
> issues, but nothing stuck.
>
> Please consider this new revision for the PT schema, which addresses most
> of the issues, while keeping as backward compatible as possible:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_v3
>
> I'd be happy to hear any suggestions. Next week, I'll be presenting it,
> among other things, during my talk "What's up with the public transport" at
> the State of the Map conference.
>
> Thanks,
> Ilya
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk-fr] [OKFILTER] [Tagging] Public Transport v3 — starting RFC

[Johnparis]

This is a very long and complex proposal, so it will take me a while to
digest and respond. I am also alerting the transport mailing lists in
English and French. I trust the RFC will be open for at least for a couple
of months.

Cette proposition (en anglais) est très longue et complexe, il me faudra
donc du temps pour digérer et répondre. J'alert également les listes de
diffusion de transport en anglais et en français. J'espère que le RFC sera
ouvert au moins pour quelques mois.

John

On Fri, Jul 20, 2018 at 3:48 PM, Ilya Zverev  wrote:

> Hi folks,
>
> As you might've noticed, in the past year there has been growing
> discomfort with the current Public Transport tagging schema. Of course, it
> brought order to our route relations, but also introduced a lot of
> redundant concepts. We've seen a couple proposals aiming to fix some of
> issues, but nothing stuck.
>
> Please consider this new revision for the PT schema, which addresses most
> of the issues, while keeping as backward compatible as possible:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport_v3
>
> I'd be happy to hear any suggestions. Next week, I'll be presenting it,
> among other things, during my talk "What's up with the public transport" at
> the State of the Map conference.
>
> Thanks,
> Ilya
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] anonymous notes spam?

[Johnparis]

When I click on the samples I get full notes. Perhaps there was a database
hiccup?

On Fri, Jul 20, 2018, 18:29 Andrew Hain  wrote:

> Can we find out what software is being used to send these notes?
>
> --
> Andrew
> --
> *From:* Doug Hembry 
> *Sent:* 20 July 2018 14:26:13
> *To:* talk@openstreetmap.org
> *Subject:* Re: [OSM-talk] anonymous notes spam?
>
> Yes. In the San Francisco Bay Area. Single letters "f", "k", and "l".
> Example:
> https://www.openstreetmap.org/note/778721#map=15/37.5009/-122.3032=N
> BTW, is there a simple way to delete such note comments?
>
> On 7/20/2018 2:32 AM, maning sambale wrote:
> > I'm getting several single letter notes comments since yesterday.
> > Example: https://www.openstreetmap.org/note/562375
> > Are people noticing the same?
> >
>
> ___
> 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: [OSM-talk-fr] Tramway sur pneu - railway=tram ou highway=bus_guideway

[Johnparis]

Bonjour,

Certes cela n'est pas un bus. Sur la liste de transit en anglais, il n'y
avait aucune doute que les T5 et T6 sont des tramways. Sur la liste en
français, pas de consensus.

Je propose
transitway=tram

Cordialement,

John





On Mon, Jul 16, 2018, 15:29 Thomas Ruchin  wrote:

> Bonjour
>
> Il existe en île de France 2 lignes de tramway sur pneu.
> https://www.openstreetmap.org/relation/5136037  --> le T6
> https://www.openstreetmap.org/#map=19/48.95351/2.35815 --> Le T5
>
> Et pour ces 2 lignes, de multiples conflits d'édition entre
> - railway=tram et highway=bus_guideway
>
> A titre personnel, je suis choqué d'un moyen de transport qui n'est pas
> sur rail puisse comporter le tag "railway". Mais d'un point de vue service
> au voyageur, cela s'approche des tram classiques. Il paraît même que c'est
> un tramway d'un point de vue législation.
>
> Bref, il me semble que tout le monde à raison et qu'il faudrait créer le
> tag "highway=tram" pour ce type d'équipement.
>
> Des avis ?
>
> Thomas
> ___
> 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] Attribution eaupotable.info

[Johnparis]

https://eaupotable.info/en/contact/

2018-07-11 9:06 GMT+02:00 Vincent Bergeot :

> Bonjour,
>
> je suis assez dubutatif sur cette carte : https://eaupotable.info/
>
> Quand on choisit en eau à gauche OpenStreetMap, on a bien le rendu OSM
> mais pas d'attributions !!!
>
> Et quand en plus on choisit à gauche OSM, on a tous les
> amenity=drinking_water qui s'affiche mais pas plus d'attributions.
>
> Par contre on voit bien en bas à gauche, quelque soit le fond, écrit
> google.
>
> Cela fait beaucoup, vous ne trouvez pas ? Je n'ai pas trouvé de contact :(
>
> Bonne journée
>
> PS : comme d'habitude, je ne retrouve pas la page wiki pour vérifier les
> signalements d’omission de mention !!!
>
> --
> Vincent Bergeot
>
>
> ___
> 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] WMF: "Interactive maps, now in your language"

[Johnparis]

https://wiki.openstreetmap.org/wiki/Names

I would especially encourage you to read the entire section "Avoid
transliteration", which also discusses translation issues.

On Sat, Jun 30, 2018 at 7:08 AM, Yves  wrote:

> While there is a lot of things said here in this thread, I notice that:
> 1 there is very little advice in the article on how to enter names in OSM.
> 2 there no comment on the blog that would give advice on how to enter
> names in OSM.
>
> It would be the right time if OSM people would take the time to synthetise
> to WMF contributors what names are acceptable in OSM.
> Do we have a good wiki page on the matter?
> Yves
> ___
> 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] WMF: "Interactive maps, now in your language"

[Johnparis]

Ha! I was going to cite that as an example. I recently removed precisely
that absurd tag in Paris.

On Fri, Jun 29, 2018, 14:06 Frederik Ramm  wrote:

> Hi,
>
> On 29.06.2018 13:44, Simon Poole wrote (quoting Wikimedia):
> > Add the missing names to OSM in your language.
>
> I think that this simply means we need much better name QA in the
> future, and must not be afraid to remove names that don't belong there.
> Until now we've practically let every language enthusiast add their
> names to places far and wide without asking for sources; in the future
> we should ask for verifiable sources.
>
> We're ready to accept a local person's authority about local features;
> but that doesn't mean that I as a speaker of German should necessarily
> have the (un-questioned) authority to assign German names to places on
> the other side of the planet.
>
> I expect that a close look at international place names from this point
> of view will probably enable us to get rid of quiet a few "Pont Neuf=New
> Bridge" type names.
>
> 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
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] [OSM transport] le début de la fin pour PTv1 ou la fin du début pour PTv2

[Johnparis]

excellent. Il y a 133 en Ile de france ; je peux les examiner.

2018-06-19 17:48 GMT+02:00 marc marc :

> Bonjour,
>
> l'équipe du rendu osm.org vient de réaliser que highway=plateform est
> complètement supplanté par public_transport=plateform
> 1 million d’occurrence pour public_transport=platform
> 84000 occurrence pour highway=platform + public_transport=platform
> 9000 occurrence pour highway=platform
>
> L'équipe en question s'apprête donc à enfin ajouter le rendu de
> public_transport=plateform
> C'est donc l'occasion de vérifier les highway=platform qui n'ont pas de
> public_transport=plateform et voir si on peux pas encoder cela de
> manière compatible avec la PTv2. la seule difficulté étant d'éviter les
> doublons (2 objets public_transport=plateform pour un seul arrêt)
>
> Voici la requête overpass https://overpass-turbo.eu/s/zGm
>
> Cette proposition est un véritable cheval de Troie : elle implique
> d'ajouter public_transport=* dans la base de rendu ce qui le rends
> disponible pour le rendu ultérieur des autres cas.
> Si on ajoute cela avec le fait que iD ajoute correctement les 2 version
> en une fois, c'est peut-être le début de la fin pour le double tag
> PTv1+PTv2 des arrêts de bus par exemple.
>
> Cordialement,
> Marc
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-transit] tram vs. bus_guideway

[Johnparis]

Thanks for the input.

I like the idea of tram:type=rubber-tyred

But the main sticking point (at least on the French list) that I've seen
seems to be the word "railway", since tram is defined as a subdivision of
that. ("How can you call it a tram if there's no steel rail?") I'm thinking
that perhaps something like

transitway=tram/bus/train/subway

might be a better tag for dedicated transit ways. (Obviously this would not
work for ways where cars share the space; those would still need a
highway=* tag rather than transitway=*)

By the way, I'm only posing this question because I was helping a newbie
who wanted to do some mapping of trams. I personally stick to mapping buses.

On balance, it seems to me that the tagging should reflect the term used to
publicize the line by the operator, rather than some esoteric technicality
knowable only to civil engineers and wiki readers. This is keeping the end
user in mind. If I am in Lyon and I know there's a tram "somewhere nearby",
but it's tagged as a bus_guideway, my search results will be:

google maps = found
bing maps = found
OSM = zero

... and I will no doubt start grumbling ...

On the other hand, if the operator advertises it as a bus, I'll have no
problem, assuming my search engine will find a bus_guideway (with stops
appropriately tagged as bus=yes).


On Tue, Jun 19, 2018 at 5:32 PM, Mateusz Konieczny 
wrote:

> After looking at https://en.wikipedia.org/wiki/Rubber-tyred_trams
> especially "The Translohr system operates as a guided vehicle at all
> times,
> while with the Bombardier system the vehicles can be driven autonomously
> as requirements dictate, such as journeys to the depot."
>
> I would define Translohr system as a tram and Bombardier system as a bus
> on a guideway.
>
> This vehicle is on the edge between these two systems, and classification
> depends on
> a definition used - so in the end I would be OK with any decision (both
> tram and
> bus_guideway are defensible).
>
> 16. Jun 2018 01:08 by ok...@johnfreed.com:
>
>
> Maybe a solution is:
>
> railway=tram
> tram: type = bus_guideway
>
>
> Maybe tram:type = rubber-tyred?
>
>
> (name stolen from https://en.wikipedia.org/wiki/Rubber-tyred_trams )
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] tram vs. bus_guideway

[Johnparis]

No, it was a private conversation that covered a lot of other ground. The
technical details are in the wiki, however, in the section on guided buses.

On Mon, Jun 18, 2018 at 6:28 PM, Mateusz Konieczny 
wrote:

>
>
>
> 16. Jun 2018 01:08 by ok...@johnfreed.com:
>
> I asked TRuchin, who gave me a technical explanation. (Apparently the
> wheels are different.)
>
>
> Is this discussion on forum, changeset discussion or other public place
> that can be linked ?
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk-fr] Blocage de contributeur

[Johnparis]

Je t'ai conseillé que la source est importante (et presque obligatoire pour
les routes planned=*). Mais un petit pas à la fois ...

C'est evident que souvent il rend visite au site, mais pas toujours.

Ma motivation est simple : c'est "mes" arrêts qu'il a souvent changé :)

Cordialement,

John

2018-06-16 1:31 GMT+02:00 marc marc :

> Bravo pour ta motivation !
> et tant mieux s'il progresse !
> il lui reste à apprendre à décrire un rien ses changesets.
> T'as une idée de la source qu'il utilise pour autant de modif ?
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Blocage de contributeur

[Johnparis]

J'ai examiné les dernier 21 changesets de RB94, est la plupart est bonne.
Mais c'est juste dans deux jours !!! Comme j'ai dit, il travaille vite.

J'ai fait un commentaire où j'ai trouvé des problèmes, particulairement
quand il a changé la sorte de highway (de service à residential) ou le nom
(toujours un problème avec lui). J'ai expliqué l'idée de séparer le nom de
la ligne de l'operateur.

Il me semble qu'il apprend assez bien.

Il vient de demander un réexamination d'un changeset !
https://www.openstreetmap.org/changeset/59885072

Alors, j'espère qu'il va devinir un bon collaborateur sur OSM. Mais je
continue à surveiller ses travaux.

Cordialement,

John




2018-06-14 5:28 GMT+02:00 Johnparis :

> Oui, je suis vraiment en contact. Il traville vite et parfois mal. (Pas
> toujours, certaines de ses contributions sont bonnes.)
>
> Je vais l'encourager de proceder plus lentement pendant ces temps.
>
> Les erreurs ne sont pas dangereuses, alors je pense que l'on peut attendre
> plus que 48 heures pour la réeducation :). Sache qu'il a commencé avec
> MAPS.ME, alors il a fait beaucoup des erreurs sans voir les critiques.
> Maintenant il utilise iD, alors il peut voir les commentaires.
>
> Merci de la patience.
>
> John
>
>
>
>
>
>
> 2018-06-13 18:34 GMT+02:00 Philippe Verdy :
>
>> Il y a des outils plus efficaces que le blocage d'IP, notamment il y a
>> des moyens de récupérer des infos privées (et les garder en lieu sûr)
>> collectées par diverses techniques, des filtres de détection bahésiens pour
>> pondérer et évaluer statistiquement certaines contributions. Il est facile
>> aussi de matcher plusieurs IP successives (parfois alternées) qui seraient
>> utilisées par un même utilisateur faisant et refaisant les mêmes
>> "constributions", ce qui permet de mettre un panneau d'alerte sur un
>> tableau de bord permettant une évaluation prioritaire afin de faire des
>> reverts plus rapides et moins nocifs et moins difficiles pour les autres
>> avant que les données se propagent et polluent les caches et obligent à
>> reconstruire sans arrêt les mêmes tuiles de carto plus souvent que
>> nécessaire.
>> Les IP sont en général non fixes mais assez stables (au moins 24 heures,
>> sinon plus pour les accès en France, sauf via les mobiles qui accèdent à
>> OSM en IPv4 via un NAT depuis une IPv4 partagée d'un opérateur mobile) au
>> lieu d'IPv6 qui lui est TRES stable.
>> Je serais OSM, je militerais pour que tous les éditeurs OSM passent en
>> priorité sur IPv6 (dont les adresses sont rarement dynamiques) chaque fois
>> que possible (et c'est généralement le cas en mobilité car l'IPv4 via le
>> NAT massif partagé des opérateurs est lent et ne permet pas des sessions
>> TCP très longues, l'IPv4 utilisée peut changer alors très rapidement toutes
>> les 5 minutes dans les zones denses, et on ne peut pas bloquer tout un
>> opérateur mobile dans une zone très peuplée sans créer de gros dommages
>> collatéraux vis-à-vis des autres utilisateurs). Utiliser IPv6 devrait être
>> même une obligation de tous les éditeurs pour mobiles sur tous les
>> téléphones et tablettes compatibles (IPv6 est déjà la norme partout en
>> Asie, et ça commence à s'imposer ailleurs).
>> Ensuite il restera le cas des VPN et proxies, mais les VPN et proxies
>> sérieux incluent des traces de suivi permettant d'identifier numériquement
>> un de leurs utilisateurs même si on ne sais pas précisément qui, mais cela
>> permet de faire des corrélations fortes, et ensuite de signaler l'usage
>> abusif à l'exploitant du VPN ou proxy qui peut prendre des mesures plus
>> contraignantes si les signalements sont trop nombreux (l'exploitant n'est
>> pas obligé de nous livrer l'identité réelle, mais les abuseurs laissent
>> souvent assez de traces pour qu'on les identifie directement, il y a
>> presque toujours des "signatures" dans les données, les textes soumis, les
>> descriptions, la typologie des erreurs systématiques, les fautes de frappe
>> ou d'orthographe les plus fréquentes, la présentation, le style, la langue
>> utilisée, et l'intérêt marqué pour certains lieux ou sujets abusés).
>>
>> Il n'est pas difficile non plus de repérer le commentaire de changeset
>> (souvent répété à l'identique ou avec juste quelques caractères modifiés),
>> les filtre bahésiens font des notes de concordances fortes. Cependant au
>> niveau du serveur OSM (via son API) on ne voit pas tout et le serveurs
>> dispose de logs plus détaillés (qui sont conservés privés mais exploitables
>> par des agents qualifiés et autorisés qui ont signé une charte de
>> confidentialité et s'interdisent de révéler autre chose que la répon

Re: [OSM-talk-fr] Maps.me et autres contributions grand public

[Johnparis]

+1

2018-06-14 8:56 GMT+02:00 Christian Quest :

>
> Voire ne permettre des contributions directes que si tu as plus de NN
> changesets à ton actif et pas tous avec l'appli utilisée ;)
>
> --
> 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] Blocage de contributeur

[Johnparis]

 aider en leur
> montrant comment faire mieux, ou en leur suggérant d'autres outils pour
> certaines modifications, ou en les guidant vers des projets collaboratifs
> plus ciblés, ainsi que vers les documentations disponibles ou en les
> mettant en contact avec d'autres utilisateurs proches ou parlant leur
> langue.
>
> En soit les erreurs ne sont pas mauvaises (c'est même comme ça qu'on
> apprend la plupart du temps), mais il faut arriver à convaincre calmement
> qu'on eput faire les choses mieux et plus facilement, ou simplement en
> évitant d'aller vite (car souvent il n'y a aucune urgence à modifier
> l'existant et on peut planifier les changements s'il y en a beaucoup à
> faire). Et OSM dispose d'outils pour ça (exemple HOTOSM avec un découpage
> fin par zones prioritaire et des objectifs ciblés sur certains aspects
> seulement, puis un passage de révision/qualification: on n'est pas obligé
> non plus de tout préciser tout de suite et il vaut mieux ne rien préciser
> qu'essayer d'introduire des données peu fiables ou supposées ou trop
> ambiguës; le reste peut se planifier sur une autre tâche réalisée plus
> tard).
>
> Le 13 juin 2018 à 17:00, Christian Quest  a
> écrit :
>
>> Après deux jours et pas d'amélioration... j'ai fait les corrections, on
>> ne va pas laisser la base se pourrir petit à petit ainsi.
>>
>> Nouveau blocage plus long ? Un blocage par IP est-il possible (si c'est
>> la même IP qui est utilisée) ?
>>
>> Le 13 juin 2018 à 15:37, Thomas Ruchin  a écrit :
>>
>>> Salut John,
>>>
>>> Tu es vraiment en contact avec RB94
>>> <https://www.openstreetmap.org/user/RB94> ? Parce que notre ami
>>> continue ses modification douteuses (il confond généralement nom et
>>> descriptions), n'a strictement rien corrigé de ses anciennes contributions
>>> et ne répond pas lorsqu'un changeset est commenté ?
>>> Pour rappel, les données notamment transports sont très utilisées par
>>> des applications extérieures, donc cela cause un dommage certain au sérieux
>>> et à la fiabilité d'OSM.
>>>
>>> Franchement, on attend vraiment qu'il ait pollué toute la base pour agir
>>> ?
>>> Pour ce genre de contributeur, il faudrait proposer 6 mois de pratique
>>> dans un bac à sable...
>>>
>>> [Marc marc, avant de demander plus d'éléments,  je t'invite à faire par
>>> toi même un tour détaillé dans les contributions de RB94 ;)]
>>>
>>> Thomas
>>>
>>> Le lun. 11 juin 2018 à 19:44, Johnparis  a écrit :
>>>
>>>> RB94 m'a repondu par l'affirmative.
>>>>
>>>> Merci de ne pas le bloquer pour le moment. Nous allons commencer par
>>>> ses changements les plus recents.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2018-06-11 19:36 GMT+02:00 :
>>>>
>>>>> Comme dit par Christian, on a été nombreux à lui tendre la main.
>>>>> En réponse un doigt d'honneur.
>>>>>
>>>>> Par exemple (anecdotique) je lui demandais de mieux préciser dans les
>>>>> changeset ce qu'il faisait.
>>>>>
>>>>> Maintenant le commentaire systématique c'est "J'ai fait quelque
>>>>> modifications bien précisés".
>>>>>
>>>>> Donc oui Johnparis, bon comportement de ta part mais sans vouloir te
>>>>> décevoir, tu n'es pas le premier à essayer.
>>>>> > tu as un exemple d'objet oü le revert précédent a oublié d'annuler
>>>>> un des modifs incorrecte ?
>>>>> Guillaume avait posté toute une liste sur la liste :
>>>>> https://etherpad.net/p/revertparis
>>>>>
>>>>> Guillaume, alors que tu as bloqué RB94, il recommence sans tenir
>>>>> compte.
>>>>> https://www.openstreetmap.org/user/RB94/blocks
>>>>> Du coup je propose un blocage plus long et par IP.
>>>>>
>>>>> Donat, la procédure c'est essayer de faire changer la pratique en
>>>>> commentant des changeset et en désespoir de cause de contacter
>>>>> d...@osmfoundation.org (ici aussi Guillaume car il a plusieurs
>>>>> qualités : inscrit sur cette liste, francophone, membre du DWG et il a
>>>>> aussi annulé des modifs de RB et bloqué au nom du DGW, ce qui fait 
>>>>> beaucoup
>>>>> pour un seul homme et c'est tant mieux !).
>>>>>
>>>>> Jean-Yvon
>>>>>
>>>>>  Message transféré 
>&g

Re: [OSM-talk-fr] Blocage de contributeur

[Johnparis]

RB94 m'a repondu par l'affirmative.

Merci de ne pas le bloquer pour le moment. Nous allons commencer par ses
changements les plus recents.






2018-06-11 19:36 GMT+02:00 :

> Comme dit par Christian, on a été nombreux à lui tendre la main.
> En réponse un doigt d'honneur.
>
> Par exemple (anecdotique) je lui demandais de mieux préciser dans les
> changeset ce qu'il faisait.
>
> Maintenant le commentaire systématique c'est "J'ai fait quelque
> modifications bien précisés".
>
> Donc oui Johnparis, bon comportement de ta part mais sans vouloir te
> décevoir, tu n'es pas le premier à essayer.
> > tu as un exemple d'objet oü le revert précédent a oublié d'annuler un
> des modifs incorrecte ?
> Guillaume avait posté toute une liste sur la liste :
> https://etherpad.net/p/revertparis
>
> Guillaume, alors que tu as bloqué RB94, il recommence sans tenir compte.
> https://www.openstreetmap.org/user/RB94/blocks
> Du coup je propose un blocage plus long et par IP.
>
> Donat, la procédure c'est essayer de faire changer la pratique en
> commentant des changeset et en désespoir de cause de contacter
> d...@osmfoundation.org (ici aussi Guillaume car il a plusieurs qualités :
> inscrit sur cette liste, francophone, membre du DWG et il a aussi annulé
> des modifs de RB et bloqué au nom du DGW, ce qui fait beaucoup pour un seul
> homme et c'est tant mieux !).
>
> Jean-Yvon
>
>  Message transféré 
> Sujet : blocking RB94
> Date : Tue, 5 Jun 2018 16:49:44 +0200
> Pour : d...@osmfoundation.org
> Copie à : Thomas Ruchin  ,
> Guillaume Rischard  ,
> Noémie Lehuby  
>
> Rayan Belhir is now using a third account, modifying wildly station names
> as he has done before.
>
> More efficient methods (ID-address, editor, locale...) may be needed!
>
> Thanks in advance.
>
> Jean-Yvon
>
>
>
>
> Le 11/06/2018 à 15:59, Christian Quest - cqu...@openstreetmap.fr a écrit :
>
> Il me semble que nous avons été nombreux à le joindre en tendant la main.
>
> Quand un contributeur persiste, s'ouvre une second puis un troisième
> compte pour continuer à contribuer malgré les blocages du DWG, on peut
> difficilement parler de bonne foi.
>
> Ce genre de situation est bien regrettable, heureusement que ça n'arrive
> pas souvent.
>
> Le 11/06/2018 à 14:14, Johnparis a écrit :
>
> Je lui ai écris, en offrant de revoir ses contributions et montrer les
> reglements, des listes de diffusion, etc. On verra. Je pense qu'il essaie
> en bonne foi d'ameliorer l'OSM, mais en vain.
>
> 2018-06-11 11:59 GMT+02:00 Donat ROBAUX :
>
>> Bonjour,
>>
>> Je viens de lui envoyer un com de changeset bien senti!
>> Je ne connais pas les procédures du DWG, mais il serait bon que le
>> blocage soit définitif non pas sur son compte mais sur son adresse ip,
>> histoire qu'on entende plus parler de lui.
>>
>> Vos avis?
>>
>> Donat
>>
>>
>>> -- Forwarded message --
>>> From: Thomas Ruchin 
>>> To: talk-fr@openstreetmap.org, Guillaume Rischard <
>>> openstreet...@stereo.lu>
>>> Cc:
>>> Bcc:
>>> Date: Mon, 11 Jun 2018 11:29:40 +0200
>>> Subject: Re: [OSM-talk-fr] Blocage de contributeur
>>> Bonjour,
>>>
>>> Il continue :
>>> https://www.openstreetmap.org/user/RB94.
>>> Exemple : https://www.openstreetmap.org/node/2799009880
>>> Par ailleurs, le problème sur ses modifications des semaines passées est
>>> que malgré le passage de plusieurs contributeurs chevronnées (Christian,
>>> Donat, Noémie, Jean-Yvon, Guillaume,...) certains jeux de données sont
>>> encore pollués par des éléments qui ne correspondent pas aux règles OSM.
>>> Par exemple, dans les nommages de voies ferrées ou dans les schémas de
>>> relations de transport.
>>>
>>> Que fait on ?
>>>
>>> Thomas
>>>
>>> Le mer. 6 juin 2018 à 00:28, Johnparis  a écrit :
>>>
>>>> Verifié, j'espère.
>>>>
>>>> 2018-06-05 19:21 GMT+02:00 Guillaume Rischard 
>>>> :
>>>>
>>>>> Bonjour,
>>>>>
>>>>> Est-ce que la communauté locale peut vérifier ces objets que je n’ai
>>>>> pas pu annuler?
>>>>>
>>>>> https://etherpad.net/p/revertparis
>>>>>
>>>>> J’ai en tout cas bloqué RB94.
>>>>>
>>>>> Guillaume, pour le Data Working Group
>>>>>
>>>>> On 5 Jun 2018, at 16:03, Thomas Ruchin  wrote:
>>>>>
>>>>> Bonjour
&g

Re: [OSM-talk-fr] Blocage de contributeur

[Johnparis]

Je lui ai écris, en offrant de revoir ses contributions et montrer les
reglements, des listes de diffusion, etc. On verra. Je pense qu'il essaie
en bonne foi d'ameliorer l'OSM, mais en vain.

2018-06-11 11:59 GMT+02:00 Donat ROBAUX :

> Bonjour,
>
> Je viens de lui envoyer un com de changeset bien senti!
> Je ne connais pas les procédures du DWG, mais il serait bon que le blocage
> soit définitif non pas sur son compte mais sur son adresse ip, histoire
> qu'on entende plus parler de lui.
>
> Vos avis?
>
> Donat
>
>
>> -- Forwarded message --
>> From: Thomas Ruchin 
>> To: talk-fr@openstreetmap.org, Guillaume Rischard <
>> openstreet...@stereo.lu>
>> Cc:
>> Bcc:
>> Date: Mon, 11 Jun 2018 11:29:40 +0200
>> Subject: Re: [OSM-talk-fr] Blocage de contributeur
>> Bonjour,
>>
>> Il continue :
>> https://www.openstreetmap.org/user/RB94.
>> Exemple : https://www.openstreetmap.org/node/2799009880
>> Par ailleurs, le problème sur ses modifications des semaines passées est
>> que malgré le passage de plusieurs contributeurs chevronnées (Christian,
>> Donat, Noémie, Jean-Yvon, Guillaume,...) certains jeux de données sont
>> encore pollués par des éléments qui ne correspondent pas aux règles OSM.
>> Par exemple, dans les nommages de voies ferrées ou dans les schémas de
>> relations de transport.
>>
>> Que fait on ?
>>
>> Thomas
>>
>> Le mer. 6 juin 2018 à 00:28, Johnparis  a écrit :
>>
>>> Verifié, j'espère.
>>>
>>> 2018-06-05 19:21 GMT+02:00 Guillaume Rischard :
>>>
>>>> Bonjour,
>>>>
>>>> Est-ce que la communauté locale peut vérifier ces objets que je n’ai
>>>> pas pu annuler?
>>>>
>>>> https://etherpad.net/p/revertparis
>>>>
>>>> J’ai en tout cas bloqué RB94.
>>>>
>>>> Guillaume, pour le Data Working Group
>>>>
>>>> On 5 Jun 2018, at 16:03, Thomas Ruchin  wrote:
>>>>
>>>> Bonjour
>>>>
>>>> Notre nouvel ami s'appelle RB94
>>>>> <https://www.openstreetmap.org/user/RB94>
>>>>
>>>>
>>>> Merci par avance pour l'action du DWG
>>>>
>>>> Thomas
>>>>
>>>> Le 28 mai 2018 à 21:44, Jérôme Seigneuret 
>>>> a écrit :
>>>>
>>>>> J'ai bien envie de te dire que les deux sont liés surtout dans ce cas
>>>>> vu que c'est un contributeur via plusieurs comptes qui vandalise des
>>>>> données ;-)
>>>>>
>>>>> Le 28 mai 2018 à 20:22,  a écrit :
>>>>>
>>>>>> OSMCha :
>>>>>>
>>>>>> https://osmcha.mapbox.com/filters?aoi=88f846df-d53b-
>>>>>> 4305-b91a-eb8b06d5c304
>>>>>> Là on s'intéresse au contributeur, pas au contenu mais on peut
>>>>>> ajouter des filtres sur le contenu.
>>>>>>
>>>>>> Le 28/05/2018 à 12:36, Christian Quest - cqu...@openstreetmap.fr a
>>>>>> écrit :
>>>>>>
>>>>>> Overpass...
>>>>>>
>>>>>> [out:xml][timeout:60];
>>>>>> // gather results
>>>>>> (
>>>>>>   // query part for: “railway=station”
>>>>>>   node["railway"="station"][name~'RATP']({{bbox}});
>>>>>>   way["railway"="station"][name~'RATP']({{bbox}});
>>>>>>   node["public_transport"="stop_position"][name~'RATP']({{bbox}});
>>>>>>   way["public_transport"="stop_position"][name~'RATP']({{bbox}});
>>>>>> );
>>>>>> // print results
>>>>>> out meta;>;out meta;
>>>>>>
>>>>>>
>>>>>> Je viens de refaire un peu de nettoyage, certaines stations / arrêts
>>>>>> étaient encore incorrects.
>>>>>>
>>>>>>
> ___
> 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] Blocage de contributeur

[Johnparis]

Verifié, j'espère.

2018-06-05 19:21 GMT+02:00 Guillaume Rischard :

> Bonjour,
>
> Est-ce que la communauté locale peut vérifier ces objets que je n’ai pas
> pu annuler?
>
> https://etherpad.net/p/revertparis
>
> J’ai en tout cas bloqué RB94.
>
> Guillaume, pour le Data Working Group
>
> On 5 Jun 2018, at 16:03, Thomas Ruchin  wrote:
>
> Bonjour
>
> Notre nouvel ami s'appelle RB94 
>
>
> Merci par avance pour l'action du DWG
>
> Thomas
>
> Le 28 mai 2018 à 21:44, Jérôme Seigneuret  a
> écrit :
>
>> J'ai bien envie de te dire que les deux sont liés surtout dans ce cas vu
>> que c'est un contributeur via plusieurs comptes qui vandalise des données
>> ;-)
>>
>> Le 28 mai 2018 à 20:22,  a écrit :
>>
>>> OSMCha :
>>>
>>> https://osmcha.mapbox.com/filters?aoi=88f846df-d53b-4305-b91
>>> a-eb8b06d5c304
>>> Là on s'intéresse au contributeur, pas au contenu mais on peut ajouter
>>> des filtres sur le contenu.
>>>
>>> Le 28/05/2018 à 12:36, Christian Quest - cqu...@openstreetmap.fr a
>>> écrit :
>>>
>>> Overpass...
>>>
>>> [out:xml][timeout:60];
>>> // gather results
>>> (
>>>   // query part for: “railway=station”
>>>   node["railway"="station"][name~'RATP']({{bbox}});
>>>   way["railway"="station"][name~'RATP']({{bbox}});
>>>   node["public_transport"="stop_position"][name~'RATP']({{bbox}});
>>>   way["public_transport"="stop_position"][name~'RATP']({{bbox}});
>>> );
>>> // print results
>>> out meta;>;out meta;
>>>
>>>
>>> Je viens de refaire un peu de nettoyage, certaines stations / arrêts
>>> étaient encore incorrects.
>>>
>>>
>>>
>>>
>>> ___
>>> 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
>>
>>
> ___
> 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] rédaction automatisée aux bus dans la région parisienne

[Johnparis]

Bonjour, Julien, et je te remercie de la question.

Le ref:FR:STIF répresente le code ZDEr_ID_REF_A dans les données STIF. Il
semble qu'il est lié au standard Reflex.

Le ref:FR:STIF:stop_id represente le code stop_id dans les données STIF.
C'est le code de GTFS (et l'identifiant unique dans ma base de données).

Cordialement,

John



2018-06-05 13:41 GMT+02:00 Julien Lepiller :

> Le 2018-06-05 13:08, Johnparis a écrit :
>
>> Bonjour,
>>
>> Je prévois une rédaction automatisée pour améliorer notre
>> couverture de deux tags existants dans la région parisienne. La
>> source de données est l'agence régionale de coordination du transit,
>> Île-de-France Mobilité, anciennement STIF.
>>
>> Il y a une question sur l'accès aux fauteuils roulants sur laquelle
>> j'aimerais recevoir des commentaires.
>>
>> S'il n'y a pas besoin d'un changement important, je prévois de la
>> faire vers le 20 juin.
>>
>> Veuillez faire des commentaires ici ou sur la page de discussion
>> jointe à la proposition:
>>
>> https://wiki.openstreetmap.org/wiki/Automated_edits/johnparis [1]
>>
>> Merci,
>>
>> John
>>
>>
>> Links:
>> --
>> [1] https://wiki.openstreetmap.org/wiki/Automated_edits/johnparis
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> Sur l'exemple que tu donnes, il y a déjà ref:FR:STIF:stop_id=StopPoint:
> 59:3926315.
> Quelle est la différence avec ref:FR:STIF=9116 ? Ça fait pas doublon ?
>
> ___
> 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] rédaction automatisée aux bus dans la région parisienne

[Johnparis]

Bonjour,

Je prévois une rédaction automatisée pour améliorer notre couverture de
deux tags existants dans la région parisienne. La source de données est
l'agence régionale de coordination du transit, Île-de-France Mobilité,
anciennement STIF.

Il y a une question sur l'accès aux fauteuils roulants sur laquelle
j'aimerais recevoir des commentaires.

S'il n'y a pas besoin d'un changement important, je prévois de la faire
vers le 20 juin.

Veuillez faire des commentaires ici ou sur la page de discussion jointe à
la proposition:

https://wiki.openstreetmap.org/wiki/Automated_edits/johnparis

Merci,

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

Re: [OSM-talk] [Imports] Automated edit for bus lines in Paris area

[Johnparis]

I wasn't familiar with IFOPT, but one of its fellow travelers, Reflex, is
associated with the "ref:FR:STIF" code in my proposal.

Thanks for this.

On Tue, Jun 5, 2018 at 12:41 PM, Stefan de Konink  wrote:

> On dinsdag 5 juni 2018 12:33:12 CEST, Johnparis wrote:
>
>> Hi, Stefan, two steps required. The second is a lot easier than the
>> first.
>> 1) curate a database of exiting nodes. Choosing a unique key usually
>> isn't difficult, especially if you are using GTFS data (stop_id is a good
>> choice). Cross-check against routes already mapped.
>>
>
> I would actually suggest also using the IFOPT information, since that is
> the physical object relation. I wonder if there is already an attribute
> there in OpenStreetMap, while the stop_id might change.
>
> 2) write a proposal. You might want to wait till the feedback here is
>> addressed! :)
>>
>
> Will do.
>
> --
> Stefan
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-transit] [Imports] [OSM-talk] Automated edit for bus lines in Paris area

[Johnparis]

I wasn't familiar with IFOPT, but one of its fellow travelers, Reflex, is
associated with the "ref:FR:STIF" code in my proposal.

Thanks for this.

On Tue, Jun 5, 2018 at 12:41 PM, Stefan de Konink  wrote:

> On dinsdag 5 juni 2018 12:33:12 CEST, Johnparis wrote:
>
>> Hi, Stefan, two steps required. The second is a lot easier than the
>> first.
>> 1) curate a database of exiting nodes. Choosing a unique key usually
>> isn't difficult, especially if you are using GTFS data (stop_id is a good
>> choice). Cross-check against routes already mapped.
>>
>
> I would actually suggest also using the IFOPT information, since that is
> the physical object relation. I wonder if there is already an attribute
> there in OpenStreetMap, while the stop_id might change.
>
> 2) write a proposal. You might want to wait till the feedback here is
>> addressed! :)
>>
>
> Will do.
>
> --
> Stefan
>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk] [Imports] Automated edit for bus lines in Paris area

[Johnparis]

Yes. It has some useful ideas that can be adapted for the GSOC project
mentioned by Jo. It doesn't really have any application to this edit,
however.

On Tue, Jun 5, 2018 at 1:00 PM, James  wrote:

> Have you taken a look at this project? https://github.com/
> CUTR-at-USF/gtfs-osm-sync
>
> On Tue, Jun 5, 2018, 6:36 AM Johnparis,  wrote:
>
>> Hi, Stefan, two steps required. The second is a lot easier than the
>> first.
>>
>> 1) curate a database of exiting nodes. Choosing a unique key usually
>> isn't difficult, especially if you are using GTFS data (stop_id is a good
>> choice). Cross-check against routes already mapped.
>> 2) write a proposal. You might want to wait till the feedback here is
>> addressed! :)
>>
>> Cheers,
>>
>> John
>>
>> On Tue, Jun 5, 2018 at 8:57 AM, Stefan de Konink 
>> wrote:
>>
>>> If this will be allowed, I would want to do the same for The Netherlands.
>>>
>>> Stefan
>>>
>>>
>>> On dinsdag 5 juni 2018 06:45:22 CEST, Mateusz Konieczny wrote:
>>>
>>>> "Summary: Adding values for two existing tags to bus stops"
>>>>
>>>>  example edit changes three tags.
>>>>
>>>> The same in the proposed changes etc comment.
>>>>
>>>> "This provides a link between the OSM node and the STIF stop_id."
>>>>
>>>> And how this match is obtained?
>>>>
>>>> Is source code of program generating matches and making edit published
>>>> somewhere?
>>>>
>>>> How edits will be split to avoid mega-edit changing thousands of
>>>> objects with massive bounding box?
>>>>
>>>> I see no mention of changeset tags - and wiki recommends adding some.
>>>>
>>>> 5 Jun 2018, 00:15 by ok...@johnfreed.com:
>>>> I am planning an automated edit to improve our coverage of two existing
>>>> tags in the Paris region. The data source is the regional transit
>>>> coordinating agency, Île-de-France Mobilité, formerly STIF.
>>>>
>>>> There is a question about wheelchair access that I would like feedback
>>>> on.
>>>>
>>>> If there is no need for a significant change, I plan to implement this
>>>> around June 20.
>>>>
>>>> Please make comments here or on the Discussion page attached to the
>>>> proposal:
>>>>
>>>> https://wiki.openstreetmap.org/wiki/Automated_edits/johnparis
>>>>
>>>> Thanks,
>>>>
>>>> John
>>>>
>>>> !DSPAM:1,5b16340e79641880612683!
>>>>
>>>
>>> --
>>> Stefan
>>>
>>>
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-transit] [Imports] [OSM-talk] Automated edit for bus lines in Paris area

[Johnparis]

Yes. It has some useful ideas that can be adapted for the GSOC project
mentioned by Jo. It doesn't really have any application to this edit,
however.

On Tue, Jun 5, 2018 at 1:00 PM, James  wrote:

> Have you taken a look at this project? https://github.com/
> CUTR-at-USF/gtfs-osm-sync
>
> On Tue, Jun 5, 2018, 6:36 AM Johnparis,  wrote:
>
>> Hi, Stefan, two steps required. The second is a lot easier than the
>> first.
>>
>> 1) curate a database of exiting nodes. Choosing a unique key usually
>> isn't difficult, especially if you are using GTFS data (stop_id is a good
>> choice). Cross-check against routes already mapped.
>> 2) write a proposal. You might want to wait till the feedback here is
>> addressed! :)
>>
>> Cheers,
>>
>> John
>>
>> On Tue, Jun 5, 2018 at 8:57 AM, Stefan de Konink 
>> wrote:
>>
>>> If this will be allowed, I would want to do the same for The Netherlands.
>>>
>>> Stefan
>>>
>>>
>>> On dinsdag 5 juni 2018 06:45:22 CEST, Mateusz Konieczny wrote:
>>>
>>>> "Summary: Adding values for two existing tags to bus stops"
>>>>
>>>>  example edit changes three tags.
>>>>
>>>> The same in the proposed changes etc comment.
>>>>
>>>> "This provides a link between the OSM node and the STIF stop_id."
>>>>
>>>> And how this match is obtained?
>>>>
>>>> Is source code of program generating matches and making edit published
>>>> somewhere?
>>>>
>>>> How edits will be split to avoid mega-edit changing thousands of
>>>> objects with massive bounding box?
>>>>
>>>> I see no mention of changeset tags - and wiki recommends adding some.
>>>>
>>>> 5 Jun 2018, 00:15 by ok...@johnfreed.com:
>>>> I am planning an automated edit to improve our coverage of two existing
>>>> tags in the Paris region. The data source is the regional transit
>>>> coordinating agency, Île-de-France Mobilité, formerly STIF.
>>>>
>>>> There is a question about wheelchair access that I would like feedback
>>>> on.
>>>>
>>>> If there is no need for a significant change, I plan to implement this
>>>> around June 20.
>>>>
>>>> Please make comments here or on the Discussion page attached to the
>>>> proposal:
>>>>
>>>> https://wiki.openstreetmap.org/wiki/Automated_edits/johnparis
>>>>
>>>> Thanks,
>>>>
>>>> John
>>>>
>>>> !DSPAM:1,5b16340e79641880612683!
>>>>
>>>
>>> --
>>> Stefan
>>>
>>>
>> ___
>> Imports mailing list
>> impo...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
>>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk] [Imports] Automated edit for bus lines in Paris area

[Johnparis]

Hi, Stefan, two steps required. The second is a lot easier than the first.

1) curate a database of exiting nodes. Choosing a unique key usually isn't
difficult, especially if you are using GTFS data (stop_id is a good
choice). Cross-check against routes already mapped.
2) write a proposal. You might want to wait till the feedback here is
addressed! :)

Cheers,

John

On Tue, Jun 5, 2018 at 8:57 AM, Stefan de Konink  wrote:

> If this will be allowed, I would want to do the same for The Netherlands.
>
> Stefan
>
>
> On dinsdag 5 juni 2018 06:45:22 CEST, Mateusz Konieczny wrote:
>
>> "Summary: Adding values for two existing tags to bus stops"
>>
>>  example edit changes three tags.
>>
>> The same in the proposed changes etc comment.
>>
>> "This provides a link between the OSM node and the STIF stop_id."
>>
>> And how this match is obtained?
>>
>> Is source code of program generating matches and making edit published
>> somewhere?
>>
>> How edits will be split to avoid mega-edit changing thousands of objects
>> with massive bounding box?
>>
>> I see no mention of changeset tags - and wiki recommends adding some.
>>
>> 5 Jun 2018, 00:15 by ok...@johnfreed.com:
>> I am planning an automated edit to improve our coverage of two existing
>> tags in the Paris region. The data source is the regional transit
>> coordinating agency, Île-de-France Mobilité, formerly STIF.
>>
>> There is a question about wheelchair access that I would like feedback on.
>>
>> If there is no need for a significant change, I plan to implement this
>> around June 20.
>>
>> Please make comments here or on the Discussion page attached to the
>> proposal:
>>
>> https://wiki.openstreetmap.org/wiki/Automated_edits/johnparis
>>
>> Thanks,
>>
>> John
>>
>> !DSPAM:1,5b16340e79641880612683!
>>
>
> --
> Stefan
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-transit] [Imports] [OSM-talk] Automated edit for bus lines in Paris area

[Johnparis]

Hi, Stefan, two steps required. The second is a lot easier than the first.

1) curate a database of exiting nodes. Choosing a unique key usually isn't
difficult, especially if you are using GTFS data (stop_id is a good
choice). Cross-check against routes already mapped.
2) write a proposal. You might want to wait till the feedback here is
addressed! :)

Cheers,

John

On Tue, Jun 5, 2018 at 8:57 AM, Stefan de Konink  wrote:

> If this will be allowed, I would want to do the same for The Netherlands.
>
> Stefan
>
>
> On dinsdag 5 juni 2018 06:45:22 CEST, Mateusz Konieczny wrote:
>
>> "Summary: Adding values for two existing tags to bus stops"
>>
>>  example edit changes three tags.
>>
>> The same in the proposed changes etc comment.
>>
>> "This provides a link between the OSM node and the STIF stop_id."
>>
>> And how this match is obtained?
>>
>> Is source code of program generating matches and making edit published
>> somewhere?
>>
>> How edits will be split to avoid mega-edit changing thousands of objects
>> with massive bounding box?
>>
>> I see no mention of changeset tags - and wiki recommends adding some.
>>
>> 5 Jun 2018, 00:15 by ok...@johnfreed.com:
>> I am planning an automated edit to improve our coverage of two existing
>> tags in the Paris region. The data source is the regional transit
>> coordinating agency, Île-de-France Mobilité, formerly STIF.
>>
>> There is a question about wheelchair access that I would like feedback on.
>>
>> If there is no need for a significant change, I plan to implement this
>> around June 20.
>>
>> Please make comments here or on the Discussion page attached to the
>> proposal:
>>
>> https://wiki.openstreetmap.org/wiki/Automated_edits/johnparis
>>
>> Thanks,
>>
>> John
>>
>> !DSPAM:1,5b16340e79641880612683!
>>
>
> --
> Stefan
>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Imports] [OSM-talk] Automated edit for bus lines in Paris area

[Johnparis]

Thanks for noting this, Jo.

I'm hoping the GSOC project will simplify fusing GTFS data to existing
nodes; that's the hard part of the curation that I've already done with the
11,000 nodes. Still 34,000 left to go, so the GSOC project could be a boon
there.

On Tue, Jun 5, 2018 at 9:03 AM, 
wrote:

> Message: 5
> Date: Tue, 5 Jun 2018 09:02:41 +0200
> From: Jo 
>
>
> A tool to help with this kind of integration is being developed as a Google
> Summer of Code project. It's in early stages and focused on GTFS feeds, but
> we can look into doing this for lists of stops with approximate coordinates
> as well.
>
> Polyglot
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [OSM-talk] Automated edit for bus lines in Paris area

[Johnparis]

replies inline

On Tue, Jun 5, 2018 at 9:03 AM, 
wrote:

>
> Message: 4
> Date: Tue, 5 Jun 2018 06:45:22 +0200 (CEST)
> From: Mateusz Konieczny 
>
> "Summary: Adding values for two existing tags to bus stops"
>
>  example edit changes three  tags.
>
>
Thanks, fixed that. I originally planned to add missing values for the
"wheelchair" tag, but I am not persuaded of the quality of the data from
STIF. So only two.


> The same in the proposed changes etc comment.
>
> Right.


> "This provides a link between the OSM node and the STIF stop_id."
>
> And how this match is obtained?
>
>
As stated in the proposal, I maintain a database of 11,000 curated nodes.
Creation of the database was quite painstaking, but you could theoretically
do it yourself (download all the bus stops, cross-check them against
existing routes, clean clean clean, notify STIF of the worst errors, clean
some more ...). This represents about 25% of all the STIF nodes. I add to
the database regularly as I map new lines (typically about 50 nodes at a
time).




> Is source code of program generating matches and making edit published
> somewhere?
>
> The matches are not generated in a programmatic sense. They are curated.

I can publish the Perl program generating the edits if you like. It could
be useful. It creates JOSM files.


> How edits will be split to avoid mega-edit changing thousands of objects
> with massive bounding box?
>
> JOSM upload with chunk size of 100. No bounding box, this edit affects
only existing nodes. When I get to the actual upload, I will probably do
1000 per changeset, then spot-check. If people think it's desirable, I
could do it as one changeset.


> I see no mention of changeset tags - and wiki recommends adding some.
>
> It's there. Search for "changeset" on the proposal page.

Thanks for your suggestions!



> 5 Jun 2018, 00:15 by ok...@johnfreed.com:
>
> > I am planning an automated edit to improve our coverage of two existing
> tags in the Paris region. The data source is the regional transit
> coordinating agency, Île-de-France Mobilité, formerly STIF.
> >
> > There is a question about wheelchair access that I would like feedback
> on.
> >
> > If there is no need for a significant change, I plan to implement this
> around June 20.
> >
> > Please make comments here or on the Discussion page attached to the
> proposal:
> >
> > https://wiki.openstreetmap.org/wiki/Automated_edits/johnparis <
> https://wiki.openstreetmap.org/wiki/Automated_edits/johnparis>
> >
> > Thanks,
> >
> > John
> >
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

[OSM-talk] Automated edit for bus lines in Paris area

[Johnparis]

I am planning an automated edit to improve our coverage of two existing
tags in the Paris region. The data source is the regional transit
coordinating agency, Île-de-France Mobilité, formerly STIF.

There is a question about wheelchair access that I would like feedback on.

If there is no need for a significant change, I plan to implement this
around June 20.

Please make comments here or on the Discussion page attached to the
proposal:

https://wiki.openstreetmap.org/wiki/Automated_edits/johnparis

Thanks,

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

[Talk-transit] Automated edit for bus lines in Paris area

[Johnparis]

I am planning an automated edit to improve our coverage of two existing
tags in the Paris region. The data source is the regional transit
coordinating agency, Île-de-France Mobilité, formerly STIF.

There is a question about wheelchair access that I would like feedback on.

If there is no need for a significant change, I plan to implement this
around June 20.

Please make comments here or on the Discussion page attached to the
proposal:

https://wiki.openstreetmap.org/wiki/Automated_edits/johnparis

Thanks,

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

Re: [Talk-transit] [OKFILTER] Talk-transit Digest, Vol 80, Issue 10

[Johnparis]

> Maybe we should, rather than blurring the line between on-street and
off-street use, make off-street the officially preferred way of mapping.

I believe that is a basic part of Jo's proposal.

I agree with those who have said:
1) one and only one relation member should be required (mandatory) for each
stop
2) other relations members should be optional but not wrong (that is, not
deprecated)



On Tue, Apr 17, 2018 at 2:00 PM, 
wrote:

> Send Talk-transit mailing list submissions to
> talk-transit@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-transit
> or, via email, send a message with subject or body 'help' to
> talk-transit-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-transit-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-transit digest..."
>
>
> Today's Topics:
>
>1. Re: stop_position proposal (Roland Olbricht)
>
>
> --
>
> Message: 1
> Date: Tue, 17 Apr 2018 06:57:13 +0200
> From: Roland Olbricht 
> To: Public transport/transit/shared taxi related topics
> 
> Subject: Re: [Talk-transit] stop_position proposal
> Message-ID: <6cf30d27-8e29-2031-8cc5-662057da5...@gmx.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Dear all,
>
> as a follow-up a statistic about whether highway=bus_stop is rather used
> on-street or off-street. The vast majority is (now) mapping bus stops
> off the street. The numbers vary, 99% of all bus stops in United Kingdom
> are mapped off street, about 80%-90% in France, Italy, and Germany. But
> also only 65% in Poland.
>
> The request is per country, here "United Kingdom" as an example. Please
> change the country to your country of interest:
> https://overpass-turbo.eu/s/xXp
> The runtime can vary, and for Germany it is several minutes.
> The important data points are the first entries on the "Data" tab.
> The results visiable on the map indicate which stops the query could not
> sort as either on-the-road or off-the-road (including being on a footway
> or similar) because it could not classify the highway value as footway
> or vehicle related. highway=pedestrian is classified as vehicle way,
> because in all the examples I have checked it has been used that way:
> https://overpass-turbo.eu/s/xXq
>
> Maybe we should, rather than blurring the line between on-street and
> off-street use, make off-street the officially preferred way of mapping.
>
> Best regards,
> Roland
>
>
>
> --
>
> Subject: Digest Footer
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
>
> --
>
> End of Talk-transit Digest, Vol 80, Issue 10
> 
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] Uploading public transport data on OSM

[Johnparis]

I believe OSM-Sync creates nodes with "gtfs_id" as the tag key. The value
is typically something like "StopPoint:48:5001".

In response to Jo/Polyglot's concern, the gtfs_id is not unique globally;
it is unique within a GTFS feed. So, for instance, the Paris area's
transport agency, STIF (now IDFM), has unique IDs within the Paris region.
It is theoretically possible that these could be duplicated somewhere else
in the world (though that likelihood is extremely small, given the
numbering scheme they use). The STIF scheme is StopPoint:x:y, where x is
the (internal STIF) code of the agency providing the stop times for each
trip, and y is an arbitrary number guaranteed to be unique within the
agency. (The agency codes are in the agency.txt file in the GTFS feed. It
gets quite arbitrary; for instance the RATP, which runs the Paris transport
system, has an agency code of 59 for purposes of bus StopPoints but a code
of 100 for some other purposes. Weird.)

I agree with Stephen Sprunk about the need to sync with a unique ID. I have
begun using gtfs_id (easily changed to, for example, ref:FR:STIF:gtfs_id),
with the idea that changes would first be synched against the existing ID.
STIF does not guarantee that the gtfs_id for a stop is permanent; however,
it seems to be the case. (STIF did guarantee that a different code would be
permanent, but it seems to have abandoned that recently, and GTFS is
becoming the de facto standard.) It makes my life a little simpler to use
gtfs_id instead of ref:FR:STIF:gtfs_id because the matching logic is
simpler. (I started with ref:FR:STIF:gtfs_id but then in JOSM for instance
I could not do a search for "gtfs_id -ref" because the "-ref" includes any
ref, even ref:FR:STIF:gtfs_id. Using just gtfs_id avoids that problem.)

The problem I run into most frequently is when someone "on the ground"
(that is, a mapper) has created a bus stop (usually with a position much
more accurate than the agency's data) but the stop doesn't have useful
information to derive the gtfs_id. (For instance, if the node had an
accurate stop name and the number of a bus line that serves it, I could
derive the gtfs_id, but often there isn't anything more informative than
"highway=bus_stop".) As a result, I have been importing nodes for each bus
line from the STIF data (with permission), then manually merging the nodes
with those already in place on the ground. I save myself lots of time when
I encounter a new line that uses existing gtfs_ids.

I have a couple of thoughts about GSoC projects for JOSM plugins that might
be useful.

-- One would deal with the aforementioned node-merging problem (an
interesting theoretical problem; mostly you want to match the closest stop
on the same side of the road, assuming it's within a reasonable distance).

-- Another would be a route-builder. My idea would be (a) I provide a
starting way and direction, (b) at the end of each way, I indicate left,
right, straight or other to continue. I think this would greatly speed the
creation of routes.

Perhaps these tools already exist. I'd love to see them.

John



>
>
> --
>
> Message: 5
> Date: Tue, 16 Jan 2018 21:35:54 +0100
> From: Jo 
> To: "Public transport/transit/shared taxi related topics"
> 
> Subject: Re: [Talk-transit] Uploading public transport data on OSM
> Message-ID:
>  gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Is there a common pattern to these GTFS IDs? Are they guaranteed to be
> unique across operators?
>
> Or is that not important and is it only important that they are stable
> between versions of GTFS files for a region?
>
> Adding a ref:gtfs tag would not be very hard to do, but I would prefer a
> scheme with ref:OPERATOR, because some stops may be served by multiple
> operators and thus be present in multiple GTFS feeds.
>
> Polyglot
>
> 2018-01-16 21:07 GMT+01:00 Stephen Sprunk :
>
> >
> >
> > What I'd like to see is some sort of tag on OSM objects (stops, routes,
> > etc.) listing the GTFS ID numbers so that tools can more easily connect
> the
> > two; that should be easy enough if someone defines a scheme and gets the
> > few relevant tools to use it.
> >
> > The lat/long for stops in GTFS data is often questionable, so it would be
> > good to have some way for folks to be able to fix the stop locations in
> OSM
> > and not get overwritten by another import later.  In many places
> > (especially in the US), GTFS data will change every few months, so if we
> > want it in OSM at all, we need a scheme that can deal with regular bulk
> > imports without losing quality where local OSM editors have improved
> things
> > by hand.
> >
> > S
> >
> > --
> > Stephen Sprunk  "Those people who think they know everything
> > CCIE #3723 are a great annoyance to those of us who do."
> > K5SSS