Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali

[emmexx]

On 12/18/19 8:46 AM, Simone Saviolo wrote:
> No. Da CdS, le biciclette sono veicoli, e a loro si applicano tutte le
> restrizioni che si applicano ai veicoli, a meno che non sia
> esplicitamente indicato. Che poi il 95% dei ciclisti non lo sappia o se
> ne freghi, è un altro discorso :)
> 
> Le ZTL (che poi altro non sono che un divieto di accesso) sono VIETATE
> alle biciclette. 
> 
> Le aree pedonali, a maggior ragione, sono VIETATE alle biciclette. 
> 
> Nel secondo caso che mostri, c'è un'esplicita eccezione per i velocipedi
> "solo condotti a mano"... cioè non è un'eccezione :) possono andare dei
> pedoni che, incidentalmente, portano una bicicletta. 

Non facciamo disinformazione.

Il Codice della Strada prevede da anni che nelle aree pedonali sia
consentito l'accesso alle bici tranne dove esplicitamente vietato.

Art 3 comma 1.2

2) Area pedonale: zona interdetta alla circolazione dei veicoli, salvo
quelli in servizio di emergenza, i velocipedi e i veicoli al servizio di
persone con limitate o impedite capacità motorie, nonché eventuali
deroghe per i veicoli ad emissioni zero aventi ingombro e velocità tali
da poter essere assimilati ai velocipedi. In particolari situazioni i
comuni possono introdurre, attraverso apposita segnalazione, ulteriori
restrizioni alla circolazione su aree pedonali.

https://www.altalex.com/documents/news/2014/02/27/disposizioni-generali#titolo

ciao
maxx

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

Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali

[Martin Koppenhoefer]

sent from a phone

> On 18. Dec 2019, at 08:47, Simone Saviolo  wrote:
> 
> Le ZTL (che poi altro non sono che un divieto di accesso) sono VIETATE alle 
> biciclette. 


le ZTL se non mi sbaglio, non sono paragonabili, perché si tratta di regole 
individuali che variano da comune a comune e anche tra le varie ztl di un 
comune. Sono semplicemente zone per le quali sono state deliberate regole 
particolari. Per esempio a Roma non ci sono ZTL che escludono biciclette, è già 
stato una ”rivoluzione“ di escludere le moto: 
https://www.omnimoto.it/news/357746/roma-ztl-a1-divieto-moto-scooter-orari-permessi/


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

Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali

[Andrea Musuruane]

On Wed, Dec 18, 2019 at 8:47 AM Simone Saviolo 
wrote:

> Il giorno mar 17 dic 2019 alle ore 11:05 Volker Schmidt 
> ha scritto:
>
>> Aree pedonali con questo segno
>>  sono aperte
>> alle bici, se non c'è un cartello con divieto esplicito come in questo
>> segno 
>>
>
> No. Da CdS, le biciclette sono veicoli, e a loro si applicano tutte le
> restrizioni che si applicano ai veicoli, a meno che non sia esplicitamente
> indicato. Che poi il 95% dei ciclisti non lo sappia o se ne freghi, è un
> altro discorso :)
>
> Le ZTL (che poi altro non sono che un divieto di accesso) sono VIETATE
> alle biciclette.
>
> Le aree pedonali, a maggior ragione, sono VIETATE alle biciclette.
>

Non mi risulta. Art. 3 comma 2 del CdS:
*Area pedonale: zona interdetta alla circolazione dei veicoli, salvo quelli
in servizio di emergenza, i velocipedi e i veicoli al servizio di persone
con limitate o impedite capacità motorie, nonché eventuali deroghe per i
veicoli ad emissioni zero aventi ingombro e velocità tali da poter essere
assimilati ai velocipedi. In particolari situazioni i comuni possono
introdurre, attraverso apposita segnalazione, ulteriori restrizioni alla
circolazione su aree pedonali. *

Ciao,

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

Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: SPAM, Re: Nommage des bâtiments scolaires / universitaires complexes

[david . crochet]

Bonjour

- Mail original -
De: "Arnaud Champollion" 
À: talk-fr@openstreetmap.org


On a des écoles élémentaire, des écoles maternelles, et des écoles primaires 
(mater+elem). Chacun de ces cas demande un seul amenity=school, sinon ça fait 
des doublons sur les rendus et sur les recherches de données. 

- Mail original -

1 établissement scolaire, ou plutôt une entité administrative, c'est 1 n° 
d'identification que l'on appelle UAI pour unité administrative immatriculée  :

3 premiers chiffres (095) qui correspondent au département (par exemple 012 
pour l’Aveyron, 095 pour le Val-d’Oise, 974 pour la Réunion...) ;
4 chiffres (1099) qui permettent d’identifier un établissement de façon unique 
dans le département ;
1 lettre (D) qui sert de checksum (ou somme de contrôle) pour vérifier la bonne 
saisie du code.

Cette dernière lettre est calculée ainsi :

on prend le nombre composé par les 7 premiers chiffres (exemple : 0951099) ;
on divise ce nombre par 23 et on garde le reste (exemple : reste de 
(0951099/23) = 3) ;
on prend ensuite les lettres de l’alphabet auxquelles on a enlevé les I, O et Q 
soient 23 lettres (a,b,c,d,e,f,g,h,j,k,l,m,n,p,r,s,t,u,v,w,x,y,z) ;
la lettre choisie est celle de la position reste + 1 (exemple : position 3+1=4, 
soit la lettre D).


Dans l'histoire, un emprise géographie, ou plutot parcellaire, peut contenir 
plusieurs établissement scolaire :
Un collège peut contenir une SGPA, donc 2 UAI pour 1 emprise géographique
Un LP et un LEGT, un LEGT et une SEP, etc. 

parfois, c'est un bâtiment, parfois, ce ne sont que des salles, parfois c'est 
juste une bureau.

Cordialement

-- 
David Crochet

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

Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali

[Simone Saviolo]

Il giorno mar 17 dic 2019 alle ore 11:05 Volker Schmidt 
ha scritto:

> Aree pedonali con questo segno
>  sono aperte
> alle bici, se non c'è un cartello con divieto esplicito come in questo
> segno 
>

No. Da CdS, le biciclette sono veicoli, e a loro si applicano tutte le
restrizioni che si applicano ai veicoli, a meno che non sia esplicitamente
indicato. Che poi il 95% dei ciclisti non lo sappia o se ne freghi, è un
altro discorso :)

Le ZTL (che poi altro non sono che un divieto di accesso) sono VIETATE alle
biciclette.

Le aree pedonali, a maggior ragione, sono VIETATE alle biciclette.

Nel secondo caso che mostri, c'è un'esplicita eccezione per i velocipedi
"solo condotti a mano"... cioè non è un'eccezione :) possono andare dei
pedoni che, incidentalmente, portano una bicicletta.

Ciao,

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

Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: SPAM, Re: Nommage des bâtiments scolaires / universitaires complexes

[Vincent Bergeot]

Le 18/12/2019 à 08:14, Arnaud Champollion a écrit :

Le 17/12/2019 à 10:35, Vincent Bergeot a écrit :

Mais du coup ça crée plusieurs amenity=school pour une seule entité.

Si par exemple on fait une requête overpass (par exemple pour 
obtenir les écoles du département et les afficher sur Umap) on ne 
risque pas de se retrouver avec des doublons ?


oui et cela dépendra de la requête, du type d'écoles attendues. 
school, school:FR, ...


[amenity=school][school:FR=élémentaire] ne renvoie normalement pas de 
doublons dans le cas évoqué 


Après avoir manipulé, lu toutes les interventions et autres docs, je 
pense qu'il faut qu'il y ait qu'un seul amenity=school par école.


Une école = une direction d'école = une entité = un amenity=school

c'est la définition administrative, pas forcément celle que l'on peut 
voir sur le terrain. Que cela soit l'intention administrative, ok mais 
pour beaucoup de cas je pense qu'il y a encore écrit école maternelle 
(même si c'est une école primaire :) )


On a des écoles élémentaire, des écoles maternelles, et des écoles 
primaires (mater+elem). Chacun de ces cas demande un seul 
amenity=school, sinon ça fait des doublons sur les rendus et sur les 
recherches de données.


j'entends très bien ce que tu écris (vraiment car je l'ai croisé un 
paquet de fois), cependant une école primaire avec une entrée pour la 
maternelle et un entrée pour l'élémentaire est aussi une réalité, la 
séparation des cours et des bâtiments sont souvent aussi des réalités du 
terrain.


Exemple avec Geodatamine : 
https://geodatamine.fr/data/education/-85909?format=csv=true


Dans l'état actuel des données OSM, le CSV généré renvoie davantage 
d'école qu'il n'y en a en réalité (L'école Paul Martin apparaît 
plusieurs fois, alors qu'il s'agit bien de la même école).


et peut-être que le problème est ailleurs alors car la requête sur 
amenity=school renvoie aussi les crêches, le conservatoire de musique, 
l'appase, l'école d'infirmiers, l'iut


peut-être faut-il des requêtes qui demande "seulement" 
[school:FR=primaire AND school:FR=élémentaire AND school:FR=maternelle 
si on parle du premier degré]


exemple ici : http://overpass-turbo.eu/s/P41


Je suppose que ce problème des doublons est identique pour tous les 
jeux de données.


oui l'extraction des données est souvent complexe :) mais pas toujours 
un problème au niveau des données (attention je ne cherche pas à dire 
qu'il n'y aurait pas des améliorations possible des modèles de données, 
y compris sur school !)


à plus






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



--
Vincent Bergeot

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

[talk-cz] Spolek OSM CR - prispevky 2020 - NEPOSILAT!

[Tom Ka]

Ahoj,

info ohledne prispevku do spolku OSM CR pro rok 2020 posleme v lednu,
zatim prosim nic neposilejte, komplikujete to ucetni i mne.

Dekuji tom.k

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

[talk-cz] WeeklyOSM CZ 490

[Tom Ka]

Ahoj, je dostupné vydání 490 týdeníku WeeklyOSM:

https://weeklyosm.eu/cz/archives/12637

* Sprinfield do OpenGeoFiction?
* Nový web maptiler.cz.
* LIDARové měření na SK.
* Výsledky voleb Nadace OSM.
* Parkování pro sdílenou jízdu.
* MapRoulette verze 3.5.
* Lepší web osm.org?
* Kritika Facebooku v OSM.
* Řízení Nadace OSM.
* Prezentace pro SotM 2020.
* Fotky a videa a SotM Africa.
* Missing Maps a Dorian.
* Kniha Digitální Země.
* Transformace tagů v OSM.
* Dobré komentáře k sadám změn.
* OpenStreetMap v TEDx.

Pěkné počtení ...

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

Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: SPAM, Re: Nommage des bâtiments scolaires / universitaires complexes

[Arnaud Champollion]

Le 17/12/2019 à 10:35, Vincent Bergeot a écrit :

Mais du coup ça crée plusieurs amenity=school pour une seule entité.

Si par exemple on fait une requête overpass (par exemple pour obtenir 
les écoles du département et les afficher sur Umap) on ne risque pas 
de se retrouver avec des doublons ?


oui et cela dépendra de la requête, du type d'écoles attendues. 
school, school:FR, ...


[amenity=school][school:FR=élémentaire] ne renvoie normalement pas de 
doublons dans le cas évoqué 


Après avoir manipulé, lu toutes les interventions et autres docs, je 
pense qu'il faut qu'il y ait qu'un seul amenity=school par école.


Une école = une direction d'école = une entité = un amenity=school

On a des écoles élémentaire, des écoles maternelles, et des écoles 
primaires (mater+elem). Chacun de ces cas demande un seul 
amenity=school, sinon ça fait des doublons sur les rendus et sur les 
recherches de données.


Exemple avec Geodatamine : 
https://geodatamine.fr/data/education/-85909?format=csv=true


Dans l'état actuel des données OSM, le CSV généré renvoie davantage 
d'école qu'il n'y en a en réalité (L'école Paul Martin apparaît 
plusieurs fois, alors qu'il s'agit bien de la même école).


Je suppose que ce problème des doublons est identique pour tous les jeux 
de données.



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

Re: [Talk-us] Trunk VS primary,

[Evin Fairchild]

Okay, this is going to be a long message, but I’d strongly suggest you read ALL 
of it before responding.

I’d first like to address the assumption that some people seem to have that 
those who support using trunk on roads other than divided highways are “tagging 
for the renderer” because we allegedly just want to see these roads appear at 
lower zoom levels. For me, that is NOT the case at all.

In reality, I support having trunk for major intercity highways because there 
needs to be more levels of indicating importance for US highways than just 
primary. For example, in Nevada, US 50 and US 6 are very lightly-traveled roads 
that only connect a few small towns in Nevada, and are known for having very 
little traffic. Tagging them as primary is perfectly fine IMO. However, US 95 
connects the two biggest cities in Nevada—Las Vegas and Reno—but it’s also 
tagged as primary. Surely US 95 between Vegas and Reno is more important than 
US 6 and US 50, right?

In my home state of Washington, there are two US routes that cross the Cascade 
Mountains, US 12 and US 2, both currently tagged as primary. Both of these 
roads are kept open in winter thru the Cascades. However, there is another road 
that crosses the Cascades, WA 20, that is also currently tagged as primary 
(which makes sense given that it is a very important cross-state highway), but 
it is NOT kept open in the winter. It doesn’t make any sense that a road that 
is not open in the winter is tagged at the same importance level as other roads 
that are kept open in the winter!

Secondly, I think some things from the wiki need to be pointed out here. On the 
wiki page for Key:highway, [1] the definition of highway=trunk is “The most 
important roads in a country's system that aren't motorways. (Need not 
necessarily be a divided highway.)” Those who say “Trunk roads should ONLY be 
divided highways, no ifs, ands, or buts” are going against what is explicitly 
stated on the wiki page for key:highway. 

Also, at the bottom of the aforementioned wiki page, there is a section 
entitled "Assumptions,” which states in the first paragraph: 

“Only highway=motorway/motorway_link implies anything about quality. Other road 
types, from highway=trunk through highway=tertiary to 
highway=residential=residential/service or highway=path/footway/cycleway/track 
do not imply anything about road quality.” 

These words speak for themselves. 

Now, if we want to indicate road quality in some way (e.g. whether a road is 
divided or not), we ought to use the expressway=* tag like others have 
suggested rather than using the highway=trunk tag just for that. 

Even if you don’t use the expressway tag, you can still tell if a trunk road is 
divided or not because the default render shows divided roads as having a 
thicker line than undivided roads. A good example can be seen by looking at 
western Canada, where the most important intercity roads are tagged as trunk 
regardless of whether they’re divided or not. [3] You can clearly tell if a 
road is divided or not even if undivided roads are tagged as trunk because the 
divided roads have a thicker line than the undivided. Therefore, it is not 
necessary to reserve highway=trunk for divided roads only.

TL;DR I support tagging undivided roads as trunk because 1) some US routes are 
more important than others and lumping them all as primary doesn’t make any 
sense; 2) the wiki says that only the motorway designation implies anything 
about quality of the road; and 3) the renderer shows divided roads with a 
thicker line than undivided roads. 

[1] https://wiki.openstreetmap.org/wiki/Key:highway#Roads
[2] https://wiki.openstreetmap.org/wiki/Key:highway#Assumptions
[3] https://www.openstreetmap.org/#map=7/51.618/-112.972

From: Greg Troxel
Sent: Tuesday, December 17, 2019 1:16 PM
To: Paul Johnson
Cc: Mike N; talk-us@openstreetmap.org
Subject: Re: [Talk-us] Trunk VS primary,

Paul Johnson  writes:

> On Tue, Dec 17, 2019 at 7:24 AM Mike N  wrote:
>
>>
>>I think many of the trunk VS motorway VS primary conflicts come from
>> 2 points of view:  on the one hand, people like to zoom out and see a
>> coherent network of interconnected roads.
>
> In which case, rendering based on network on the route relations would be
> more appropriate.

This is the crux of the matter.  Calling things trunk so they render is
tagging for the renderer in a bad way.

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

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

Re: [Talk-us] Alaska Highway AK-2 tagging

[Bradley White]

> Long term, it would be nice to separate these notions and have some
> highway:importance key for that, and leave the road type notion that
> separates primary/trunk/motorway alone (or move it to some other tag,
> and get rid of highway=trunk and highway=motorway).

Ideally, this is what 'highway' is already supposed to represent
(https://wiki.openstreetmap.org/wiki/Proposed_features/Highway_key_voting_importance).
The debate fundamentally is over whether roads built to "expressway"
standards are de facto important enough to warrant being their own
class of importance, in the same way that freeways are in the US
(given that the US has a national interstate system). I think there
are convincing cases for both tagging schemes, but that ultimately we
need to make a decision as a community, since using both is ambiguous
and confusing.

> I guess you are suggesting to add highway=expressway to have expressway
> mean "sort of motorway but not quite" and change trunk to be "very
> important".  I am afraid that with so much established tagging the only
> reasonable approach to orthogonalization is to adopt two new tags for
> the things in question and deprecate the old way, allowing for a long
> and messy transition.

If 'trunk' became defined as "most important roads", I would suggest
adding a tag like 'expressway=yes/traditional/super_two/...', default
'no', to indicate the built design of the road. There has already been
such a proposal for a while, though currently abandoned:
https://wiki.openstreetmap.org/wiki/Proposed_features/Expressway_indication

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

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

[François Lacombe]

Le mer. 18 déc. 2019 à 02:06, Jérôme Amagat  a
écrit :

>
> Donc si on suis cette logique, il faut changer en building=tourism tous
> les hôtels, en building=amenity tous les restaurants, lieu de culte, bar,
> école... pour avoir une belle chaîne de tag.
>

Uniquement si le bâtiment est complètement dédié à ces destinations, en
tout cas pour ce qui nous intéresse ici.
Que ce principe ne soit pas en vigueur partout, c'est en partie à cause de
l'historique (particulièrement marqué sur building) et aussi parce que
certains concepts ne sont pas aussi liés que la destination d'un bâtiment
aux équipements qu'il héberge.

OSM est une base sémantique, chaîner les concepts me semble être une
pratique vertueuse.
Utiliser deux termes, service sur building et utility ensuite, pour la même
chose n'est pas bon non plus (et on ne redéfinira pas service=* pour ça)


> On le laisse comme on laisse building=church sur une église reconverti en
> musée, habitation...
> C'est la plupart du temps la destination première du bâtiment que l'on met
> dans building=* mais si l'utilisation change le tag building=* ne doit pas
> changer.
>

Ce qui rend la signification de building=* moins claire que ce je
pensais... c'est la destination, puis la forme, on ne sais pas bien.
La première destination d'un bâtiment remonte à autant qu'on puisse se
souvenir... c'est plutôt pas clair.


> Il est beaucoup utilisé, ce qui posera sûrement problème, mais facile à
>> comprendre, non
>> Service ça veut tout et rien dire, vraiment.
>>
>
> C'st plus facile à comprendre que "utility" !
>

Question d'appréciation, je ne sais toujours pas ce que veux dire service
(intrinsèquement, sinon j'ai bien lu le wiki). Qu'est-ce que tu comprends ?
Par contre utility, on a une définition et un périmètre clairs, au moins
pour les pays développés : https://en.wikipedia.org/wiki/Public_utility


> D'ailleurs le bâtiment qui stocke le sel pour le déneigement des routes à
>> côté de chez moi, c'est building=service ou pas ? (parce que c'est pas une
>> "utility" mais les véhicules garés devant sont tous stickés "SERVICE").
>>
>
> Je dirais que si le bâtiment a été construit pour le stockage c'est plutôt
> building=warehouse.
>

D'accord avec ça

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

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

[osm . sanspourriel]

Le 18/12/2019 à 00:28, François Lacombe - fl.infosrese...@gmail.com a
écrit :


Si on documente la destination d'un bâtiment, pourquoi devrait-on
laisser building=garage si celui-ci deviens une habitation?
Il y a bien des silos de lancement de missiles balistiques qui
deviennent des appartements, on voit de tout.


Tant qu'ils ont l'aspect typique de l'objet précédent ça a un sens. Ce
n'est pas la destination mais l'aspect qui compte.

Après si tu mets par exemple un toit pentu sur le garage,
building=garage sera remplacé par building=house.

Le 18/12/2019 à 02:05, Jérôme Amagat - jerome.ama...@gmail.com a écrit :

Donc si on suis cette logique, il faut changer en building=tourism
tous les hôtels, en building=amenity tous les restaurants, lieu de
culte, bar, école... pour avoir une belle chaîne de tag.


Pourquoi pas mais seulement si c'est une architecture typique.

Le 18/12/2019 à 02:05, Jérôme Amagat - jerome.ama...@gmail.com a écrit :


Service ça veut tout et rien dire, vraiment.


C'st plus facile à comprendre que "utility" !


Il faut effectivement penser aux locuteurs étrangers (non britanniques).
Je pense que l'avis de Jérôme reflète le cas de la majorité des Français.

Et pour services style garagiste, il y a aussi la station-service... où
maintenant c'est toi qui fait le service !

Et c'est vrai que si je vois ce que sont les "utilities", j'aurais
tendance à focaliser sur les entreprises du secteur énergétique (et non
à l'ensemble des services de réseau).

Jean-Yvon

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

Re: [OSM-talk-fr] Joli noms de rues

[osm . sanspourriel]

Le 16/12/2019 à 19:54, Jérôme Amagat - jerome.ama...@gmail.com a écrit :

le "rue du Repos pour ne pas dire "cimetière" est un peu mieux...


Voir la rue de l'avenir mais il faut un conseil municipal pourvu
d'humour. Et les administrés aussi !

Le 16/12/2019 à 21:58, Christian Rogel -
christian.ro...@club-internet.fr a écrit :

Ce qui est demandé, c’est que l’on exploite le nom lieu incrit dans le cadastre 
pour nommer les voies.

+1, ça s'appelle le bon sens

Par ailleurs, sachant que c’est la commune qui a tous les pouvoirs sur la forme 
des noms de voie, rien ne l’oblige à choisir « générique »  en français (rue, 
allée…), si elle préfère qe ce générique soit dans une autre langue (hent, 
carrer, strasse, etc.) ou, pourquoi pas, l’absence de générique.
C’est donc à la Poste d’enregistrer tous les génériques possibles et de 
s’adapter au terrain et no l’inverse.
D’autant qu’il s’agit, aujourd’hui, d’un organise privé.


Les génériques dans le cas de strasse sont à la fin.

Et Gerberstrasse, c'est le rue des tanneurs, ce n'est pas à côté de la
rue de la soif^^ (qui n'ont pas toutes été renommées Rue Saint-Michel
 - alors que là l'usage
persiste)


L’espoir pourrait venir de… l’IGN qui pourrait faire ce travail si évident. Et 
comme l’IGN alimente la BAN qui pourrait parvenir aux oreilles des maires…un


Ou les cartographes d'OSM, je ne sais si tu en as entendu parler.

Ce sont des gens bizarres avec notamment un type encore plus bizarre
qu'ils appellent vdct. Non seulement ils créent une carte alors que
Google fait le boulot gratuitement heu met à disposition gratuitement
heu met à disposition contre argent une carte.

Avec des quartiers nommé par Google. Et au final tu donnes ton adresse
Google.

Ce vdct il fait des trucs de dingue. Il a été "recruté" pas un autre
fana, Christian du même genre. Je mets des guillemets car ils
travaillent bénévolement. Et puis pour faire ce qu'ils font tous les
deux, il faudrait plusieurs service de l'IGN.

Et bien imagine toi ces gens-là mettent à disposition les lieux-dits du
cadastre.
Et d'autres bénévoles les intègrent dans la carte, un truc de ouf.

Et un promoteur en mal d'inspiration ou au contraire inspiré va utiliser
ces toponymes pour nommer ses prestations.

Le 16/12/2019 à 22:27, Philippe Verdy - verd...@wanadoo.fr a écrit :

Certains noms sont historiques: un service peut disparaître aussi,
comme "Rue de la Gare" (alors qu'il n'y a plus de gare ni même de voie
ferrée) et ne rend plus service à personne.


Par contre le bâtiment gare peut être resté. C'est alors comme l'église
qui a changé de destination : ce n'est plus une gare ou une église, et
ça ne rend plus ce service. Une gare qui sert d'office de tourisme
 ça a une utilité mais plus
la même et sert toujours de repère dans le paysage.

Tiens il faudra changer ce building=yes.


De même "Rue de la Mare" quand il n'y a plus de mare non plus. Ou
Place de grève à Paris quand il n'y a plus de grève (en tant cas pas
avec le même sens qu'on comprend aujourd'hui). Le service est utile
mais limité dans le temps quand le service est déplacé ailleurs (une
marie, un cimetière).


La place de grève

s'appelle /Place de l'Hôtel-de-Ville - Esplanade de la Libération/ et
était une grève (au sens du lieu formé de gravier sur une rive) et a
donné le nom de grève pour l'embauche et in fine pour faire grève dans
le sens de refuser l'embauche et rester sur la place de grève.

Vu que ça a créé l'acceptation du sens faire grève c'est un peu bête de
ne pas avoir gardé le nom. D'ailleurs je crois que les endroits ou les
dockers embauchaient (quand ils étaient journaliers - et pas des images
oui j'ai osé^^) s'appelaient place de grève par imitation de la place de
Paris.


Tant qu'à faire autant utiliser "Rue/route du ", au
moins les hameaux et lieux-dits persistent longtemps à moins que tout
soit démoli et plus habité. Quant à "Rue de 
c'est souvent assez ambigu quadn ce n'est même plus le chemin préféré
pour y aller suite à un changement de plan de circulation.

Et ça devient "ancienne route de Trucmuch", bof effectivement. Ou trop
peu descriptif, comme cette Rue de la Rade
 à Roskañvel (toutes les
routes est-ouest côté Est peuvent porter ce nom).


Maintenant j'aime bien les noms insolites, comme "Rue de la Pie qui
boit" (je vous laisse chercher où) qui évoque toute une histoire à
raconter, un folklore, une ancienne tradition, ou une invention d'un
auteur pour une scène de oman, de théatre ou de cinéma se passant dans
la commune.


Effectivement je me rappelai l'avoir remarquée en passant mais je ne me
souvenais plus de la ville. Merci Nominatim.


Mais d'une façon générale, si une rue héberge un monument ou
quelquechose de remarquable comme un bâtiment classé, c'est une
mauvaise 

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

[Jérôme Amagat]

Le mer. 18 déc. 2019 à 00:29, François Lacombe 
a écrit :

> Bonsoir Jérôme,
>
> Le lun. 16 déc. 2019 à 01:34, Jérôme Amagat  a
> écrit :
>
>>
>> C'est joli mais qu'est ce que ça apporte de plus comme info que
>> building=service + power=substation + substation=minor_distribution ?
>>
>
> Avec building=service, on se sais pas de quel service il peut s'agir.
> Un garagiste c'est aussi un service finalement (on me l'a déjà sorti plein
> de fois).
>
> Il est réellement intéressant de pouvoir construire des chaînes comme ce
> que je montrais dans le mail du dessus.
> Si le consommateur est intéressé pour trouver tout le bâti impliqué dans
> les utilités, il ne connaît peut-etre pas les valeurs plus spécifiques
> comme power=substation et il peut en oublier.
>

Donc si on suis cette logique, il faut changer en building=tourism tous les
hôtels, en building=amenity tous les restaurants, lieu de culte, bar,
école... pour avoir une belle chaîne de tag.

>
>
>>  L'architecture d'un garage est le plus souvent très éloigné de celle
>> d'une maison, ou d'une église. Ce qui ressemble le plus à un garage c'est
>> un autre garage, une grande porte, pas ou seulement des petites ouverture,
>> bâtiment pas très haut, ils sont pas tous comme ça mais beaucoup. Pour
>> building=service on peut faire la même chose, il y a sûrement plus de cas
>> différents que pour le garage.
>> Malgré ça je suis d'accord que ce que l'on met dans building=* donne plus
>> d'info sur à quoi il sert que sur le bâtiment en lui même mais on demande
>> par exemple de laissé building=church même si ça ne sert plus de lieu de
>> culte et il faudrait laissé building=garage même si le bâtiment est devenu
>> (sans trop de modif) une habitation...
>>
>
> Si on documente la destination d'un bâtiment, pourquoi devrait-on laisser
> building=garage si celui-ci deviens une habitation?
>

On le laisse comme on laisse building=church sur une église reconverti en
musée, habitation...
C'est la plupart du temps la destination première du bâtiment que l'on met
dans building=* mais si l'utilisation change le tag building=* ne doit pas
changer.
la page du wiki donne le tag building:use=* pour l'usage (
https://wiki.openstreetmap.org/wiki/Key:building) mais je ne n'ai jamais
utilisé ce tag.
La plupart du temps l'usage on l'ajoute avec d'autre tag, un bâtiment qui
sert de restaurant c'est amenity=restaurant quelque soit le tag building=*


> Il y a bien des silos de lancement de missiles balistiques qui deviennent
> des appartements, on voit de tout.
>

le bâtiment doit être tagué avec building=missile silo ou quelque chose
comme ça.

>
>
>> Si j'en reviens au problème de départ :) , rien n’empêche d'indiquer avec
>> un autre tag à quoi sert ce bâtiment et pourquoi pas avec utility=*, on
>> peut déjà le faire avec d'autres tags, par exemple, une église convertie en
>> musée c'est building=church + tourism=museum il n'y a pas besoin de
>> building=tourism ou autre chose.
>> On peut privilégié une valeur comme building=utility lorsque le bâtiment
>> a été construit à cet effet mais je pense que building=service a l'avantage
>> d'être plus simple à comprendre et est déjà beaucoup utilisé.
>>
>
> Il est beaucoup utilisé, ce qui posera sûrement problème, mais facile à
> comprendre, non
> Service ça veut tout et rien dire, vraiment.
>

C'st plus facile à comprendre que "utility" !


> D'ailleurs le bâtiment qui stocke le sel pour le déneigement des routes à
> côté de chez moi, c'est building=service ou pas ? (parce que c'est pas une
> "utility" mais les véhicules garés devant sont tous stickés "SERVICE").
>

Je dirais que si le bâtiment a été construit pour le stockage c'est plutôt
building=warehouse.


> Même si le wiki semble utiliser building=service pour building=utility, je
> ne suis pas sûr en plus que toutes les occurrences soient concernées par le
> changement proposé. Certains bâtiments ne doivent pas être des sites
> techniques d'utilités à proprement parler.
>
> Bref, il y a besoin d'en discuter encore un peu
>
> Bonne soirée
>
> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-us] Preliminary Import/Organized Mapping Effort Idea

[Mike Thompson]

Village Earth's Native Land Advocacy Project[1], David Bartecchi[2], Paul
Johnson[3], and I[4] are considering an organized effort to improve the
boundaries of Native American Reservations in the US.  We have studied the
import guidelines on the wiki and will follow those, however, we first
wanted to see:

1) If there was any fundamental objection to this idea before even the
details are spelled out

2) If anyone is already working on this issue.

3) If anyone would like to join us.


We are thinking that our general approach will be:

1) Use data from this source:
https://biamaps.doi.gov/dataDownload/index.htmlIt has a compatible
license, but will verify and document as part of this process.

2) Somehow allow mappers to "check out" a particular reservation's
boundary.  Exact mechanism is TBD.

3) A human mapper will examine each boundary individually

4) Where OSM does not have a corresponding reservation boundary, the mapper
will import the boundary into OSM (not sure of the exact mechanics at this
time).  If the boundary needs to participate in a boundary relation, that
will be handled here. Tag mapping is TBD at this point.   Any conflicts
with existing OSM features will be addressed in this step.

5) Where OSM has a boundary and it does not match the above source, and it
has not been edited by a human mapper, proceed as in 4 above, except only
replace geometry and preserve the history of the existing OSM features.

6) Where OSM has a boundary and it does not match our source, but it has
been edited by a human mapper, use additional sources, including tribal
sources, and county sources, to determine the true boundary and make
necessary edits in OSM.  Deference will be given to the edits made by local
mappers.

To be determined:
We are aware of some cases where different government bodies (e.g. Federal
Government vs. a state government) dispute the extent of a reservation.

Long term we would like to involve Native Americans, particularly youth
living on reservations, in adding additional details to OSM about
reservations, such as street names, amenities, etc., but we don't envision
this as part of this import/organized effort process.

We look forward to your initial feedback on this preliminary concept.

Mike


[1] Village Earth is a 501(c)(3) nonprofit organization that has worked in
Indian Country for over 20 years and works closely with the Indian Land
Tenure Foundation
[2] David works for Village Earth
[3] Most people on this list are probably familiar with Paul, a long time
contributor to OSM
[4] My OSM user name is tekim, I have been mapping in OSM since 2009.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alaska Highway AK-2 tagging

[Paul Johnson]

On Tue, Dec 17, 2019 at 3:05 PM Greg Troxel  wrote:

> Tod Fitch  writes:
>
> > My reading of the wiki indicates that for the United States a trunk is
> “a high speed Arterial Divided highway that is partially grade separated.”
> [1]
> >
> > What is the problem with having the main road between
> regions/cities/towns being “primary”? Do you like the rendering of trunk
> better?
> >
> > For myself if I planned a driving trip and was expecting a trunk road
> I’d sure be surprised to find areas that are undivided and apparently, from
> other responses in this thread, unpaved in sections.
>
> Agreed.  To me trunk means:
>
>   paved
>   divided
>   very few at grade intersections or driveways (one every few miles is ok)
>

I'm also willing to include single-carriageway (ie, undivided) freeways,
reserving motorway for something identical to substantially typical
Interstate standard fare.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[François Lacombe]

Bonsoir Jérôme,

Le lun. 16 déc. 2019 à 01:34, Jérôme Amagat  a
écrit :

>
> C'est joli mais qu'est ce que ça apporte de plus comme info que
> building=service + power=substation + substation=minor_distribution ?
>

Avec building=service, on se sais pas de quel service il peut s'agir.
Un garagiste c'est aussi un service finalement (on me l'a déjà sorti plein
de fois).

Il est réellement intéressant de pouvoir construire des chaînes comme ce
que je montrais dans le mail du dessus.
Si le consommateur est intéressé pour trouver tout le bâti impliqué dans
les utilités, il ne connaît peut-etre pas les valeurs plus spécifiques
comme power=substation et il peut en oublier.


>  L'architecture d'un garage est le plus souvent très éloigné de celle
> d'une maison, ou d'une église. Ce qui ressemble le plus à un garage c'est
> un autre garage, une grande porte, pas ou seulement des petites ouverture,
> bâtiment pas très haut, ils sont pas tous comme ça mais beaucoup. Pour
> building=service on peut faire la même chose, il y a sûrement plus de cas
> différents que pour le garage.
> Malgré ça je suis d'accord que ce que l'on met dans building=* donne plus
> d'info sur à quoi il sert que sur le bâtiment en lui même mais on demande
> par exemple de laissé building=church même si ça ne sert plus de lieu de
> culte et il faudrait laissé building=garage même si le bâtiment est devenu
> (sans trop de modif) une habitation...
>

Si on documente la destination d'un bâtiment, pourquoi devrait-on laisser
building=garage si celui-ci deviens une habitation?
Il y a bien des silos de lancement de missiles balistiques qui deviennent
des appartements, on voit de tout.


> Si j'en reviens au problème de départ :) , rien n’empêche d'indiquer avec
> un autre tag à quoi sert ce bâtiment et pourquoi pas avec utility=*, on
> peut déjà le faire avec d'autres tags, par exemple, une église convertie en
> musée c'est building=church + tourism=museum il n'y a pas besoin de
> building=tourism ou autre chose.
> On peut privilégié une valeur comme building=utility lorsque le bâtiment a
> été construit à cet effet mais je pense que building=service a l'avantage
> d'être plus simple à comprendre et est déjà beaucoup utilisé.
>

Il est beaucoup utilisé, ce qui posera sûrement problème, mais facile à
comprendre, non
Service ça veut tout et rien dire, vraiment.
D'ailleurs le bâtiment qui stocke le sel pour le déneigement des routes à
côté de chez moi, c'est building=service ou pas ? (parce que c'est pas une
"utility" mais les véhicules garés devant sont tous stickés "SERVICE").
Même si le wiki semble utiliser building=service pour building=utility, je
ne suis pas sûr en plus que toutes les occurrences soient concernées par le
changement proposé. Certains bâtiments ne doivent pas être des sites
techniques d'utilités à proprement parler.

Bref, il y a besoin d'en discuter encore un peu

Bonne soirée

François



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

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

[Christian Quest]

Aucune idée, pour cet itinéraire à 120t, l'info provient du département.
Chaque département produit une carte avec les itinéraires pour les convois
exceptionnels.

Pour les hauteurs maxi, le panneau est obligatoire en dessous de 4,30m. Il
me semble que sur les autoroutes, l'indication commence au delà.

Rien trouvé lors d'une rapide et délicieuse* lecture des instructions
interministérielles sur la signalisation routières (IISR) qu'on peut
consulter ici:
http://www.equipementsdelaroute.equipement.gouv.fr/les-versions-actualisees-des-9-parties-de-l-a528.html

* déliceuse quand je suis passé voir ce qui se racontait sur les panneaux
biche ;)


Le mar. 17 déc. 2019 à 21:31, pepilepi...@ovh.fr  a
écrit :

> Le 17/12/2019 à 17:00, Christian Quest a écrit :
>
> Bug corrigé, halo passé en gris (rouge ça faisait "bouchons")
>
> *72 t*... *petit joueur*:
> http://osm.cquest.org/fortissimo/#14/48.1961/3.3036
>
> C'est un concours à qui qu'a la plus grosse ?
>
> Juste pour ma culture, quel est le poids maxi par défaut, c'est à dire en
> l'absence de toute signalisation ?
>
> Merci, bonne soirée
>


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

Re: [OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo

[François Lacombe]

Bonsoir Deuzeffe,

Le lun. 16 déc. 2019 à 21:59, deuzeffe  a écrit :

>
> Si ma voix a un quelconque poids, elle ne s'y oppose pas.
>

C'est au contraire tout ce qui me manquait pour passer à l'action
Le wiki a déjà la nouvelle page :
https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:gdo

Le déplacement aura lieu d'ici fin décembre

Bonne soirée

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

Re: [Talk-pe] Retos de MapRoulette de Perú

[Andrew Wiseman via Talk-pe]

Saludos,

Actualicé los retos con datos nuevos. Hay una pagina aquí con todos los retos 
incluyendo caminos cruzando, carreteras flotantes, vías superpuestas, problemas 
de enrutamiento y otros. También hay un reto nuevo sobre inconsistencias de 
ortografía del nombre del camino -- cuando vías conectadas tienen nombres 
similares.

https://maproulette.org/browse/projects/38881

Muchas gracias,

Andrew 


Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 


> On Jan 28, 2019, at 4:19 PM, Andrew Wiseman  wrote:
> 
> Hola OSM Peru,
> 
> Esto es Andrew del equipo de mapas de Apple. Llevamos algún tiempo trabajando 
> en el red vial (https://github.com/osmlab/appledata/issues/52 
> ) y recientemente usado 
> nuestro herramienta Atlas para análisis de datos 
> (https://github.com/osmlab/atlas ) para 
> buscar algunos tipos de posibles problemas, como carreteras con ángulos 
> agudos, intersecciones de edificios y carreteras, y lugares donde la 
> clasificación de “highway_link” no coincide con la clasificación más alta de 
> las carreteras. Pongo los resultados de los retos en MapRoulette 
> (maproulette.org ), un herramienta que te permite 
> pasar los problemas uno por uno y corregirlos o marcar que no son un 
> problema. Quería hacerles saber que estaban disponibles en caso de que 
> alguien quisiera intentar arreglarlos. Yo también arreglaré algunos.
> 
> En MapRoulette escoges un problema random o haz clic en un problema 
> especifico. Si desea ver tareas en un lugar determinado, como en un lugar con 
> el que está familiarizado, puede hacer clic en "más opciones" y luego en 
> “load tasks by proximity” (cargar tareas por proximidad.)
> 
> Por favor, hágamelo saber si tiene alguna pregunta o comentario.
> 
> Los retos son:
> 
> Carreteras de ángulo agudo: https://maproulette.org/mr3/challenge/3553 
> 
> Intersecciones de edificios y carreteras: 
> https://maproulette.org/mr3/challenge/3551 
> 
> Carreteras de enlaces: https://maproulette.org/mr3/challenge/3555/ 
> 
>  
> Muchas gracias,
> 
> Andrew
> 
> 
> 
> Andrew Wiseman |  Maps | iPhone: +1.202.270.4464 | andrew_wise...@apple.com 
> 

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

Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: Nommage des bâtiments scolaires / universitaires complexes

[Brice]

Le 15/12/2019 à 17:32, Arnaud Champollion a écrit :
OK, et du coup serait-il cohérent de fusionner les bâtiments dès lors ceux ceux-ci constituent le même corps 
architectural ?


à mon avis non, autant rester cohérent au cadastre et conserver des corps de bâtiments séparés car des tags spécifiques* 
éventuellement ajoutés par la suite ne s'appliqueront bien qu'à un bâtiment en particulier.


* par exemple :
https://wiki.openstreetmap.org/wiki/Simple_3D_buildings

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

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

[deuzeffe]

Le 17/12/2019 à 16:44, Vincent de Château-Thierry a écrit :

Bonjour,


Bonsoir,


1/ Tout d'abord, le "ref:FR:FANTOIR" doit être placé au niveau du
way ou de la relation ?


De la relation. On met sur la relation tout ce qui peut être
factorisé, donc le nom de voie (tag name=* dans la relation) et le
ref:FR:FANTOIR puisqu'il dépend du nom de voie.


Grmblbl, tu sais que, parfois, je te hais ?
--
deuzeffe - on verra plus tard :/

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

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

[deuzeffe]

Le 17/12/2019 à 14:22, Quentin Salles a écrit :

Bonjour deauzeffe,

Rassure-moi : les arrêts en question sont bien dans une relation (avec
les voies) ie un trajet, elle-même dans la relation globale qui regroupe
tous les trajets ?
Oui l'ensemble des lignes se trouvent dans une relation "network"


Ouf ;) Donc, operator et network (dont "Tisséo") sur les relations 
(trajets + relation maître) devraient suffire à retrouver ce que tu 
cherches, non ?


Et comme je disais, je souhaitais ce changement de tag car d'autres 
réseaux l'ont fait. 


Certes. Je ne sais pas si c'est une bonne raison :P
--
deuzeffe

Après, je peux toujours faire un rétropédalage de la 
clé "ref"


Quentin SALLES

Le sam. 14 déc. 2019 à 11:43, deuzeffe > a écrit :


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

Bonjour,

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

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

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

-- 
deuzeffe - partisane de l'effort optimal


 > Quentin SALLES
 >
 > Le ven. 13 déc. 2019 à 17:55, laurent-38
mailto:laurent.riffard%2bnab...@free.fr>
 > >> a écrit :
 >
 >     Frédéric Rodrigo-2 wrote
 >      > Le principe des règles, c'est de corrigé les données, pas
les règles.
 >      > La règle est valide et basé sur le wiki OSM.
 >      >
 >      > Le 10/12/2019 à 14:48, Quentin Salles a écrit :
 >      >> …
 >      >> Aujourd'hui, Osmose
 >      >> signale tous les arrêts de bus ayant un mauvais suffixe
 >     d'attribut sur
 >      >> la clé "ref:FR:Tisséo".
 >
 >     Bonjour Frédéric,
 >
 >     Peux-tu préciser le sens de ta réponse ?
 >
 >     S’agit-il de supprimer les accents dans les clés tels que
 >     ref:FR:Tisséo (ou
 >     ref:Transisère) ? Le wiki ne me semble pas l’interdire :
 > https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Characters
 >
 >     Ou bien s’agit-il d’enregistrer ces clés dans une « liste
blanche »,
 >     type
 >

https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales,
 >     pour qu’elles soient considérées comme correctes ?
 >
 >     Cordialement
 >     ~~
 >     laurent
 >
 >
 >
 >     --
 >     Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
 >
 >     ___
 >     Talk-fr mailing list
 > Talk-fr@openstreetmap.org 
>
 > https://lists.openstreetmap.org/listinfo/talk-fr
 >
 >
 > ___
 > Talk-fr mailing list
 > Talk-fr@openstreetmap.org 
 > https://lists.openstreetmap.org/listinfo/talk-fr
 >

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


___
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-us] Trunk VS primary,

[Greg Troxel]

Paul Johnson  writes:

> On Tue, Dec 17, 2019 at 7:24 AM Mike N  wrote:
>
>>
>>I think many of the trunk VS motorway VS primary conflicts come from
>> 2 points of view:  on the one hand, people like to zoom out and see a
>> coherent network of interconnected roads.
>
> In which case, rendering based on network on the route relations would be
> more appropriate.

This is the crux of the matter.  Calling things trunk so they render is
tagging for the renderer in a bad way.

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

[OSM-talk-fr] Fwd: [osm-grenoble] Projet Europeen de l'Eau/European Water Project - Introduction

[François Lacombe]

Bonsoir à tous,

Je relaye ici le message de Stuart qui a pris la peine de présenter ce
projet sur la liste local-grenoble.
Cela peut en intéresser certains

François

-- Forwarded message -
De : European Water Project 
Date: mar. 17 déc. 2019 à 10:57
Subject: [osm-grenoble] Projet Europeen de l'Eau/European Water Project -
Introduction
To: 


Bonjour,

Je m'appelle Stuart Rapoport. J'habite Divonne les Bain dans l'Ain.

Nous nous lançons dans un projet collaboratif qui est 100% Open Data et
utilise exclusiviement des données d'OpenStreetMap, Wikidata et Wikimedia
Commons. Notre toute nouvelle (et très petite) ONG Suisse  Projet Européen
de l'Eau (European Water Project) a but d'inciter les personnes de boire
l'eau du robinet et d’arrêter d’acheter des bouteilles à usage unique,
notamment celles en plastique.

J'ai écrit une Progressive Web Application en HTML5, CSS et Javascript que
vous pouvez télécharger sans passer par l'Apple Store ou le Google Store à
https://europeanwaterproject.org. Pour peupler les fontaines sur notre
carte, nous faisons tourner un script en nodejs qui extrait les données
d'OSM par l'API Overpass et  celles de Wikidata par l'API SPARQL.

Pour l'instant nous nous concentrons sur les fontaines d’eau potable en
Europe, mais nous voulons dans un deuxième temps participer dans le
développement d’un réseau de cafés et de restaurants qui sont d'accord pour
remplir des gourdes d'eau gratuitement pour toute personne qui le demande.

Nous présentons notre APP pour la première fois, le 8 janvier devant 860
étudiants de 48 pays.

Je voulais savoir si je pouvais venir le week-end du 15-16 février pendant
votre CA pour présenter rapidement notre projet ?

Je vous prie d'excuser mes fautes de français.

Cordialement,

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

Re: [Talk-us] Alaska Highway AK-2 tagging

[Greg Troxel]

Bradley White  writes:

> The lack of consistent highway tagging in the US is one of the biggest
> sources of frustration with this project as a whole to me. IMO, the US
> community needs to make a decision to *either*:
>
> 1. Use 'trunk' to mean "major cross-country highway" and orthogonalize
> expressway constructions with its own 'expressway=*' tag, bump
> 'primary' to "minor cross-country highway/major regional highway",
> 'secondary' to "minor regional highway/major local road", etc...
>
> Or:
>
> 2. Use 'trunk' to mean strictly "partially grade-separated limited
> access divided highway" (with explicit instruction to not tag singular
> or isolated interchanges as 'motorway')
>
> The mixture of the two schemes that leans towards one or the other
> depending on what part of the country you're in is inconsistent and
> confusing to me, and judging by how many times we've gone in circles
> about this on us-talk, others as well.

Agreed.  I think option 2 is the right path.  primary used to mean
important long-distance route, before people started calling local roads
primary.

Long term, it would be nice to separate these notions and have some
highway:importance key for that, and leave the road type notion that
separates primary/trunk/motorway alone (or move it to some other tag,
and get rid of highway=trunk and highway=motorway).

As for the freeway/expressway notion, note that this is regional
langauge and we don't walk that way in Boston (we're too busy running
red lights and using our horns!!).  But seriously, I don't know those
distinctions and people don't really use those words.

I guess you are suggesting to add highway=expressway to have expressway
mean "sort of motorway but not quite" and change trunk to be "very
important".  I am afraid that with so much established tagging the only
reasonable approach to orthogonalization is to adopt two new tags for
the things in question and deprecate the old way, allowing for a long
and messy transition.

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

Re: [Talk-us] Alaska Highway AK-2 tagging

[Greg Troxel]

Tod Fitch  writes:

> My reading of the wiki indicates that for the United States a trunk is “a 
> high speed Arterial Divided highway that is partially grade separated.” [1]
>
> What is the problem with having the main road between regions/cities/towns 
> being “primary”? Do you like the rendering of trunk better?
>
> For myself if I planned a driving trip and was expecting a trunk road I’d 
> sure be surprised to find areas that are undivided and apparently, from other 
> responses in this thread, unpaved in sections.

Agreed.  To me trunk means:

  paved
  divided
  very few at grade intersections or driveways (one every few miles is ok)

basically "sort of like a motorway, but not quite".

primary already means "this is a very main road".

There are plenty of primary roads with 65 MPH speed limits out there.
If they aren't divided or have more-than-occasional at-grade
intersections or driveways, that's the right classification.

I don't think a road that isn't physically trunk should get tagged as
such just because it is the most important road (or the only road).

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

Re: [Talk-GB] Disused or empty apartments prior to demolition

[David Woolley]

On 17/12/2019 20:35, Warin wrote:


so
building=apartments
becomes
disused:building=apartments

or
building=yes
becomes
disused:building=yes


I disagree.  It is still a building.  In fact some of the most 
interesting buildings are disused ones.


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

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

[Philippe Verdy]

Le mar. 17 déc. 2019 à 20:36, Yves P.  a écrit :

>
> Et là aussi (sauf qu’il faut décharger 10t) :
> http://osm.cquest.org/fortissimo/#17/48.19065/3.31208
>

Seulement si le poids lourd passe de la route sortante à la rocade de
Sens... Si on reste sur la sortante Paris-Genève sans emprunter la rocade
de Sens (donc en passant au centre-ville), c'est 120t limite pour sortir du
centre-ville par là : il faudra donc sortir ailleurs (en passant par le
centre de Maillot, le sud de Malay-le-Grand, la route de Noé, etc.).

Ca a du sens mais il n'y a pas beaucoup de voies de grande capacité pour
les super-lourds.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Disused or empty apartments prior to demolition

[Warin]

My understanding?


If the feature is disused then place disused: in front of the existing tag;

so
building=apartments
becomes
disused:building=apartments

or
building=yes
becomes
disused:building=yes


Having both disused:building=* and disused:building=* is a conflict, it 
is disused or not?


OSM does not map history, the past use of a building is not what 'we' 
map. OSM does map what the building 'looks' like - apartments, church, 
post office etc. Using the disused: tag does not change this, but adds 
the information that it is presently disused.


On 18/12/19 03:58, Silent Spike wrote:
The `building` tag actually specifies the original purpose or form of 
the building - it just happens that this usually aligns with the 
current use. As such, I think it's fine to leave them tagged as 
`building=apartments`.


See: 
https://wiki.openstreetmap.org/wiki/Key:building:use. Interestingly 
that wiki page points to the lifecycle prefix page for the case of 
disused buildings, but I'd say feel free to use `building:use=disused` 
to explicitly tag them for future mappers to see.


On Tue, Dec 17, 2019 at 3:22 PM Jez Nicholson > wrote:


Change it to building=yes + disused:building=apartments ?...it's
still a building, but the original use is now disused?

- Jez

On Tue, 17 Dec 2019, 14:51 Gareth L, mailto:o...@live.co.uk>> wrote:

There are some tower blocks near me which have been emptied of
residents ahead of eventual demolition of the buildings.
They’re not coming back into use due to issues with their
construction.
http://www.mapillary.com/map/im/lzDlWfY8iYo2cUVmO1FNmQ/photo They’re
boarded up to secure them in the interim.

All the guidance I can find on the abandoned or disused tags
are to leave the building as defined but to use
abandoned/disused prefix on the amenity.

These didn’t have an amenity though. They do still exist on
the ground, but no longer function as apartments.

I’d like to use construction style tagging, but it doesn’t
feel quite right looking at all examples I’ve found. e.g.
Building=disused
Disused=apartments

What have you used for buildings which are awaiting
demolition, or are undergoing a protracted demolition process
but are not amenities?

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

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



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



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

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

[pepilepi...@ovh.fr]

Le 17/12/2019 à 17:00, Christian Quest a écrit :
> Bug corrigé, halo passé en gris (rouge ça faisait "bouchons")
>
> *72 t*... *petit joueur*:
> http://osm.cquest.org/fortissimo/#14/48.1961/3.3036

C'est un concours à qui qu'a la plus grosse ?

Juste pour ma culture, quel est le poids maxi par défaut, c'est à dire
en l'absence de toute signalisation ?

Merci, bonne soirée

JP

>
> Le mar. 17 déc. 2019 à 16:36,  > a écrit :
>
>
> Bonjour
>
> Mais ici ( http://osm.cquest.org/fortissimo/#15/49.4170/0.2732 )
> ce n'est pas une aberration, mais bien réelle puisque c'est une
> voie utilisable par les transports exceptionnels
>
> Cordialement
> -- 
> David Crochet
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> -- 
> Christian Quest - OpenStreetMap France
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question


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

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

[Yves P.]

> Bug corrigé, halo passé en gris (rouge ça faisait "bouchons »)
Ok, mais gris c’est à peine visible. Bleu ?

> 72t... petit joueur: http://osm.cquest.org/fortissimo/#14/48.1961/3.3036 
> 
Très fort aussi le segment XXXt à faire en zeppelin 
http://osm.cquest.org/fortissimo/#17/48.17649/3.36493
http://osm.cquest.org/fortissimo/#17/47.96591/3.38238

Et là aussi (sauf qu’il faut décharger 10t) :
http://osm.cquest.org/fortissimo/#17/48.19065/3.31208


Et aussi pour passer les ponts (ça sent le « bug »):
http://osm.cquest.org/fortissimo/#17/48.07671/3.29744
http://osm.cquest.org/fortissimo/#17/48.00348/3.32508
http://osm.cquest.org/fortissimo/#18/47.99605/3.32701
http://osm.cquest.org/fortissimo/#17/47.96813/3.39894
http://osm.cquest.org/fortissimo/#16/47.8560/3.5449

Et encore ici :
http://osm.cquest.org/fortissimo/#17/48.20358/3.31267
http://osm.cquest.org/fortissimo/#17/48.22421/3.29063
http://osm.cquest.org/fortissimo/#17/48.07671/3.29744

Il y a quoi dans le secteur, un sous traitant d’Ariane Espace ?

Et là, ça fait bizarre, en zoomant un peu on a la réponse :
http://osm.cquest.org/fortissimo/#14/48.2706/3.2931

Et enfin ici, il faut vider le camion ?
http://osm.cquest.org/fortissimo/#15/48.4029/3.2407
http://osm.cquest.org/fortissimo/#16/48.2349/3.6006
http://osm.cquest.org/fortissimo/#16/47.8492/3.5520
(c’est la fin de tes données de test ?)

Le rendu du fond est très lisible 

—
Yves

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

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

[lenny.libre]

Bonsoir

Le 17/12/2019 à 16:44, Vincent de Château-Thierry a écrit :

Bonjour,


De: "Quentin Salles" 
2/ Que faire des voies qui ne comportent pas de rapprochement
OSM/Cadastre ?
http://cadastre.openstreetmap.fr/fantoir/#insee=31044=0
Il vaudrait mieux que tu utilise la page 
https://dev.cadastre.openstreetmap.fr/fantoir/#insee=31044=1

- Par exemple, sur le lien ci-dessus, "AV DU BICENTENAIRE 1789-1989"
est inscrit sur le fichier FANTOIR. Sur la commune, les plaques de
rue n'affiche que "AV DU BICENTENAIRE". Que faut-il choisir entre
les 2 ?



Dans OSM on privilégie le terrain, donc ici ça penche pour le choix 'Avenue du 
Bicentenaire'. Comme FANTOIR diverge, le fait d'ajouter le tag ref:FR:FANTOIR 
permettra de considérer dans BANO que 'Avenue du Bicentenaire' et 'AV DU 
BICENTENAIRE 1789-1989' sont la même voie. C'est la valeur du tag 
ref:FR:FANTOIR qui permettra le lien, car la comparaison des textes de nom de 
voie échouera.


D'ailleurs sur la page dev.cadastre.openstreetmap, on voit que "AV DU 
BICENTENAIRE 1789 1989" de FANTOIR a été rapprochée avec "Avenue du 
Bicentenaire" d'OSM


car le tag "ref:FR:FANTOIR" avait été saisi ; quand le rapprochement est 
fait automatiquement, le tag il est inutile.


cordialement

leni


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

Re: [Talk-GB] Disused or empty apartments prior to demolition

[Silent Spike]

The `building` tag actually specifies the original purpose or form of the
building - it just happens that this usually aligns with the current use.
As such, I think it's fine to leave them tagged as `building=apartments`.

See: https://wiki.openstreetmap.org/wiki/Key:building:use. Interestingly
that wiki page points to the lifecycle prefix page for the case of disused
buildings, but I'd say feel free to use `building:use=disused` to
explicitly tag them for future mappers to see.

On Tue, Dec 17, 2019 at 3:22 PM Jez Nicholson 
wrote:

> Change it to building=yes + disused:building=apartments ?...it's still a
> building, but the original use is now disused?
>
> - Jez
>
> On Tue, 17 Dec 2019, 14:51 Gareth L,  wrote:
>
>> There are some tower blocks near me which have been emptied of residents
>> ahead of eventual demolition of the buildings. They’re not coming back into
>> use due to issues with their construction.
>> http://www.mapillary.com/map/im/lzDlWfY8iYo2cUVmO1FNmQ/photo They’re
>> boarded up to secure them in the interim.
>>
>> All the guidance I can find on the abandoned or disused tags are to leave
>> the building as defined but to use abandoned/disused prefix on the amenity.
>>
>> These didn’t have an amenity though. They do still exist on the ground,
>> but no longer function as apartments.
>>
>> I’d like to use construction style tagging, but it doesn’t feel quite
>> right looking at all examples I’ve found. e.g.
>> Building=disused
>> Disused=apartments
>>
>> What have you used for buildings which are awaiting demolition, or are
>> undergoing a protracted demolition process but are not amenities?
>>
>> Gareth
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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

[Christian Quest]

Bug corrigé, halo passé en gris (rouge ça faisait "bouchons")

72t... petit joueur: http://osm.cquest.org/fortissimo/#14/48.1961/3.3036

Le mar. 17 déc. 2019 à 16:36,  a écrit :

>
> Bonjour
>
> Mais ici ( http://osm.cquest.org/fortissimo/#15/49.4170/0.2732 ) ce n'est
> pas une aberration, mais bien réelle puisque c'est une voie utilisable par
> les transports exceptionnels
>
> Cordialement
> --
> David Crochet
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

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

[Vincent de Château-Thierry]

Bonjour,

> De: "Quentin Salles" 
> 
> Je compte faire un peu de mis à jour sur ma commune au niveau des
> adresses et j'aimerai avoir des informations de votre part.
> 1/ Tout d'abord, le "ref:FR:FANTOIR" doit être placé au niveau du way
> ou de la relation ?

De la relation. On met sur la relation tout ce qui peut être factorisé, donc le 
nom de voie (tag name=* dans la relation) et le ref:FR:FANTOIR puisqu'il dépend 
du nom de voie.

> 2/ Que faire des voies qui ne comportent pas de rapprochement
> OSM/Cadastre ?
> http://cadastre.openstreetmap.fr/fantoir/#insee=31044=0
> - Par exemple, sur le lien ci-dessus, "AV DU BICENTENAIRE 1789-1989"
> est inscrit sur le fichier FANTOIR. Sur la commune, les plaques de
> rue n'affiche que "AV DU BICENTENAIRE". Que faut-il choisir entre
> les 2 ?

Dans OSM on privilégie le terrain, donc ici ça penche pour le choix 'Avenue du 
Bicentenaire'. Comme FANTOIR diverge, le fait d'ajouter le tag ref:FR:FANTOIR 
permettra de considérer dans BANO que 'Avenue du Bicentenaire' et 'AV DU 
BICENTENAIRE 1789-1989' sont la même voie. C'est la valeur du tag 
ref:FR:FANTOIR qui permettra le lien, car la comparaison des textes de nom de 
voie échouera.

> - Que signifie "Ok" lorsqu'il n'y a pas de rapprochement avec OSM ?

Tu as une doc ici : 
https://wiki.openstreetmap.org/wiki/Contribuer_%C3%A0_la_BANO#Interface_de_contr.C3.B4le_et_de_saisie_Fantoir.2FOSM
'Ok' est la valeur par défaut.

vincent

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

[OSM-talk-nl] OSGeo.nl/OSM-NL/QGIS-NL Nieuwjaarsborrel 12 jan 2020 Dudok, Hilversum

[Just van den Broecke]

Beste Mensen,

De OSGeo.nl traditionele Nieuwjaarsborrel met OpenStreetMap Nederland in 
Cafe Dudok, Hilversum t/o station NS, (bovenzaal) . Opgeven via OSGeoNL 
Meetup: [1] .


Dit keer ook samen met de kersverse QGIS-Gebruikers Groep Nederland [2]. 
Ook maken we hier plannen voor 2020. Als je voorstellen hebt of iets 
wilt organiseren, of wil laten zien wat je in 2019 gedaan hebt en in 
2020 wilt gaan doen, dit is een plek om te laten weten! We doen dit keer 
alleen korte 5-minuut "pitches" 1 a 2 slides van 15:30-16:30, voor de 
rest: borrrelen!


Ben je nooit eerder op een OSGeo.nl event geweest? Schroom niet om langs 
te komen als je interesse hebt in Open Source en Open Data voor Geo. 
Opgeven via Meetup [1] dus.


[1] https://www.meetup.com/OSGeoNL/events/267249156
[2] 
http://www.qgis.nl/2019/11/21/kort-verslag-oprichtingsvergadering-qgis-gebruikersgroep/


Tot dan dan, Groet!

Just van den Broecke
voorzitter OSGeo.nl


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

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

[david . crochet]

Bonjour

Mais ici ( http://osm.cquest.org/fortissimo/#15/49.4170/0.2732 ) ce n'est pas 
une aberration, mais bien réelle puisque c'est une voie utilisable par les 
transports exceptionnels

Cordialement
-- 
David Crochet

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

Re: [Talk-GB] Disused or empty apartments prior to demolition

[Jez Nicholson]

Change it to building=yes + disused:building=apartments ?...it's still a
building, but the original use is now disused?

- Jez

On Tue, 17 Dec 2019, 14:51 Gareth L,  wrote:

> There are some tower blocks near me which have been emptied of residents
> ahead of eventual demolition of the buildings. They’re not coming back into
> use due to issues with their construction.
> http://www.mapillary.com/map/im/lzDlWfY8iYo2cUVmO1FNmQ/photo They’re
> boarded up to secure them in the interim.
>
> All the guidance I can find on the abandoned or disused tags are to leave
> the building as defined but to use abandoned/disused prefix on the amenity.
>
> These didn’t have an amenity though. They do still exist on the ground,
> but no longer function as apartments.
>
> I’d like to use construction style tagging, but it doesn’t feel quite
> right looking at all examples I’ve found. e.g.
> Building=disused
> Disused=apartments
>
> What have you used for buildings which are awaiting demolition, or are
> undergoing a protracted demolition process but are not amenities?
>
> Gareth
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] Disused or empty apartments prior to demolition

[Gareth L]

There are some tower blocks near me which have been emptied of residents ahead 
of eventual demolition of the buildings. They’re not coming back into use due 
to issues with their construction.
http://www.mapillary.com/map/im/lzDlWfY8iYo2cUVmO1FNmQ/photo They’re boarded up 
to secure them in the interim.

All the guidance I can find on the abandoned or disused tags are to leave the 
building as defined but to use abandoned/disused prefix on the amenity.

These didn’t have an amenity though. They do still exist on the ground, but no 
longer function as apartments.

I’d like to use construction style tagging, but it doesn’t feel quite right 
looking at all examples I’ve found. e.g.
Building=disused
Disused=apartments

What have you used for buildings which are awaiting demolition, or are 
undergoing a protracted demolition process but are not amenities?

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

Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali

[Volker Schmidt]

On Tue, 17 Dec 2019 at 12:34, Martin Koppenhoefer 
wrote:

> non so se esiste in Italia, un marciapiede con segno "libero per bici" (in
> Germania: Fahrräder frei), solitamente viene taggato highway=footway,
> bicycle=yes e le regole sono come nel tuo caso 1 (bici ospiti dei pedoni).
>
Di quello che so io, non esiste in Italia, o forse è simile alle piste
cicpedonali condivise (segno blu pedoni sopra bici sotto), che in effetti
sono simile alla situazione che descrivo tu: percorso misto, precedenza ai
pedoni, senz obbligo di uso (in caso che sia parallelo a una strada)
In Germania, lo stesso segnale blu ha significato diverso, in particolare
include l'obbligo d'uso.

>
> Non trovo differenza tra bicycle=no e bicycle=dismount, perché entrambi i
> tags si riferiscono a biciclette, perché una bicicletta condotta a mano è
> come una bottiglia d'acqua o un cappello rosso: non conta, si diventa
> pedone a tutti gli effetti.
>
So che sei di diversa opinione su questo, ma in questo contesto non
importa.

Quello che mi confonde: 2 segnali quasi uguali (pedone in cerchio blu)
> hanno 2 significati molto diversi: se si tratta di una "zona" le bici
> possono entrare, invece se si tratta di un altro tipo di percorso no?
>
Non confonde solo te. Ci ho messo sei anni in bici per strade in Italia
prima di aver avuto la buona idea di invitare un esperto FIAB a Padova per
farci una presentazione su "Codice della Strada per Ciclisti". Posso
confermarti che è proprio cosi: I pedone su segno blu rotondo vieta il
ciclisti in sella. Lo stesso cartello, piu picolo in combinazione colla
scritta "Area Pedonale" lo permette, se non c'è una scritta supplementare
che lo esclude .
Per consolarti alcunai anni fa ho avuto un diverbio con due vigili a
Firenze che facevano scendere due cicloturiste americane che erano in sella
alle loro bici nella zona pedonale al Ponte Veccho.


Ci sono altre inconsistenze, ben più pericolose nei vari regolamenti che
compongono il cosidetto Codice della Strada in Italia.

Volker

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

[talk-cz] Tip na překlad OSM wiki

[Tom Ka]

Ahoj,

ve Weekly jsem narazil na zmínku o wiki stránce s radami pro dobré
komentáře pro sady změn, která chybí CZ i SK:

https://wiki.openstreetmap.org/wiki/Good_changeset_comments

Tak pokud se někdo bude chtít realizovat, tohle by mohlo být užitečné.

Bye tom.k

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

Re: [OSM-talk-fr] adresse mail rejetée

[Philippe Verdy]

Note: le 30 octobre j'ai arrêté d'utiliser l'adresse Wanadoo.fr mais
j'utilise l'adresse Gmail.com; cependant je suis toujours abonné aux deux
donc je peux recevoir (mais pas répondre forcément si je reçois encore des
messages par l'adresse historique Wanadoo.fr (qui n'a jamais cessé de
fonctionner depuis ~30 ans bien que j'ai changé plusieurs fois de FAI et de
régions; raison pour laquelle j'ai toutes mes anciennes adresses qui fon
ctionnent encore redirigées vers Gmail, que je peux lire aussi depuis
n'importe quel poste, même quand j'en change, ce que je ne pourrais pas
faire avec un client à stockage local type Thunderbird)

Mais je n'ai jamais utilisé le Webmail vraiment merdique de Wanadoo devenu
Orange dans le navigateur, car trop de pub et filtres de classement de
courrier trop limités, passoire aussi aux mails malveillants, et trop
d'anomalies sur leurs serveurs SMTP non standards lors de ses envois; le
Webmail d'Orange en plus ne protège pas des contenus HTML "actifs": cookies
traceurs, scripts, audio/vidéo, etc qui s'activent tout de suite dans la
boite de réception standard où presque tout passe, et les serveurs SMTP
d'Orange sont plein de trous de sécurité jamais corrigés, et pas tous
déclarés correctement dans les DNS et les certificats SSL!). Bref ma boite
Orange filtre un peu (presque rien) mais renvoie tout à Gmail qui est lui
bien plus efficace et bien plus pratique à utiliser.

Ca fait pas loin de 20 ans que je n'utilise plus les clients de courrier
locaux (POP3 ou IMAP) et je considère le stockage Gmail plus sur que sur
mon portable ou n'importe quel PC (je sais que Google peut indexer une
partie du contenu pour fournir un peu de pub, mais au moins ses pubs sont
vérifiées et pas trop gênantes, pas comme le mail de Crosoft (local ou
webmail) bourré d'arnaques et de pubs vraiment affligeantes: fake news en
pagaille, "blagues" stupides, spammeurs de tout bord qui vont vous harceler
au téléphone, et pubs vraiment gênantes pour la navigation ou même ma
consultation des mails au dessus desquels se superpose ces pubs
envahissantes; pire: le blocage de pub conduit vite à un blocage du
webmail, la composition de message est très erratiques, trop de messages
perdus en court de frappe, ça plante trop souvent, ou leurs serveurs sont
trop souvent en panne et perdent des données, et il n'y a aucune
authentification des émetteurs de messagers qu'on reçoit chez Orange, le
truc utilisant un système interne totalement propriétaire et invérifiable)
et la capacité de stockage cxhez Orange est beaucoup trop restreinte
(sature trop souvent à cause du volume de spams entrants: il vaut mieux
rediriger ailleurs, ça fait un double filtrage: en partie chez Orange,
l'autre chez Gmail, cela ajoute souvent même pas 10 secondes de délai pour
la réception des messages relayés, mais à priori je ne perds rien sauf si
la liste OSM.org reçoit un bounce d'Orange, ce qui arrive environ 1 ou 2
fois par mois mais finit par arriver quand même le lendemain ou dans la
semaine qui suit, parfois avec un entête ajouté dans le texte du mail par
Orange qui ne se préoccupe pas du tout de préserver l'intégrité des
messages avec au moins des pièces jointes conformes aux signatures
numériques).

Je note cependant que parfois il y a des bounces temporaires d'Orange vers
Gmail, mais le message finit par être remis, là encore avec un entête
supplémentaire (en gros 3 ou 4 par mois, pas plus, mais plus souvent pour
les mails envoyés par un expéditeur chez LaPoste)


Le lun. 16 déc. 2019 à 10:58, Jean-Claude Repetto  a
écrit :

> Le 16/12/2019 à 10:47, Francois Gouget a écrit :
> >
> > Concernant les emails de Philippe Verdy, pareil pour moi : je ne reçois
> > plus ses emails depuis le 2018-10-26. En fait je croyais qu'il avait
> > quitté la liste. Je n'ai pas regardé s'il y avait d'autres emails qui ne
> > me parviennent plus mais clairement il y a quelque chose qui n'est pas
> > normal là-dessous. Mais évidemment rien ne me permet de dire si ses
> > emails génèrent des bounces chez mon opérateur où si ça coince encore
> > avant : voir point 2 ci-dessus...
>
> Idem pour moi (je suis aussi chez Free): dernier message de P. Verdy
> reçu le 30/10/2018. Et j'ai encore été désabonné hier, pour la troisième
> fois en quelques jours.
>
> Jean-Claude
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


Le lun. 16 déc. 2019 à 10:58, Jean-Claude Repetto  a
écrit :

> Le 16/12/2019 à 10:47, Francois Gouget a écrit :
> >
> > Concernant les emails de Philippe Verdy, pareil pour moi : je ne reçois
> > plus ses emails depuis le 2018-10-26. En fait je croyais qu'il avait
> > quitté la liste. Je n'ai pas regardé s'il y avait d'autres emails qui ne
> > me parviennent plus mais clairement il y a quelque chose qui n'est pas
> > normal là-dessous. Mais évidemment rien ne me permet de dire si ses
> > emails génèrent des bounces chez mon opérateur où si ça 

Re: [Talk-us] Alaska Highway AK-2 tagging

[brad]

I'm not expressing strong opposition because consistency with the 
adjacent highways is important, and also because I don't live up there, 
but the wiki makes sense, trunk is a divided highway. Both this: 
https://wiki.openstreetmap.org/wiki/United_States/Road_classification#Trunk


and the US section of this:

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk

say that.

On 12/16/19 6:42 PM, Eric H. Christensen via Talk-us wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

‐‐‐ Original Message ‐‐‐
On Monday, December 16, 2019 8:21 PM, Anthony Costanzo  
wrote:


Given how these and other major
single-carriageway roads in northern and western Canada are tagged as
Trunk, tagging AK 2 as such would seem to be the option that defers to
regional precedent.

Given the discussion we've had so far, unless there is strong opposition to 
doing so, I'm going to updating the tagging of AK-2 to 'trunk' from Canada to 
Eielson AFB for consistency.  This is what it's tagged in the Yukon and, as 
SteveA points out, the differences between Trunk and Primary are little.

This has been a very good discussion, though.

R,
Eric Sparks
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsFcBAEBCAAGBQJd+DJ4AAoJEIB2q94CS7PRk9QP/1r2BJ0oXsDgko/ohA9a
EWDUgL+cR01GSBak4wJmSBXyFaeoOKcBEPRMsPq0iLE4VOXjkycJy9GwuXdr
ojYF1wc7xADtdpUkZ08D2EttJEVbMM4UDSDHIIEQjaQD8mnthN0afnrIiVSI
Icmr54t/UlieoIl4LCyyzrzn5O1vTXgLZWjcP7jcpK49Arvsrwm2ZB4TVUEa
PJSVBjfQTM++mCG1ERr/L65abEETydYSvLT8e1TEAnbP/qYdta/nqDyGoEun
O9annjr1XTfk8FcUAaAIzE/kFUQNOkMQ0q9dMl2HduWfAKHlIP3+b7UgrXdl
o5gxXDuOKT9S35KVMOle4v5WW1la6rdoX3bm6uGKO5s8WgG6tvusCRURbXhE
d3tEC5mNQh4tg2n+J/KX3xYxIK1v++7PxXuvIK4j+xDzbFmy3ynzWt2BgeG/
bWxy2BsPYiEpc9TD54LTroMIB3Qsg7YhMWbjxe1IMpKQIrqa1NitGTQdZadd
af9ge15T9iiN0PKfGpf86/t1l/I/ABhROQPwdguCbJExobPNuBSz6DiyFAZU
j+1UeIxTGr2mh6AMUVioxO3hoPb+YxrPIF3H6mpk7AtlSOHlX7C4a8Paoprb
K1wGieDEbS71yxLmTfJE7qPrSMcvDh8SDqiORB3ODng+4A2ZTBEp0QCPeNqU
lpjE
=yYTA
-END PGP SIGNATURE-


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


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

Re: [Talk-us] Alaska Highway AK-2 tagging

[Bradley White]

On Mon, Dec 16, 2019 at 4:53 PM  wrote:

> On the West Coast, several important State highways are tagged as trunks
> even though they are not full expressways, because they are the main road
> for a large region. For example, see US 199, US 101, CA 99 and CA 299 on
> this map of far Northern California:

FWIW - I am the one who bumped each of these roads listed up to trunk
a year or two ago, and I have recently bumped them back down to
primary (what they were for years before IIRC) to remain consistent
with guidelines posted here:
https://wiki.openstreetmap.org/wiki/United_States_roads_tagging and
here: https://wiki.openstreetmap.org/wiki/United_States/Road_classification

The lack of consistent highway tagging in the US is one of the biggest
sources of frustration with this project as a whole to me. IMO, the US
community needs to make a decision to *either*:

1. Use 'trunk' to mean "major cross-country highway" and orthogonalize
expressway constructions with its own 'expressway=*' tag, bump
'primary' to "minor cross-country highway/major regional highway",
'secondary' to "minor regional highway/major local road", etc...

Or:

2. Use 'trunk' to mean strictly "partially grade-separated limited
access divided highway" (with explicit instruction to not tag singular
or isolated interchanges as 'motorway')

The mixture of the two schemes that leans towards one or the other
depending on what part of the country you're in is inconsistent and
confusing to me, and judging by how many times we've gone in circles
about this on us-talk, others as well.

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

Re: [Talk-us] Trunk VS primary,

[Paul Johnson]

On Tue, Dec 17, 2019 at 7:24 AM Mike N  wrote:

>
>I think many of the trunk VS motorway VS primary conflicts come from
> 2 points of view:  on the one hand, people like to zoom out and see a
> coherent network of interconnected roads.


In which case, rendering based on network on the route relations would be
more appropriate.


>In the end, this would suffer from the same connectivity issue:
> should the US highway remain a trunk as it reduces to 2 lanes and drops
> to 30mph passing through a tourist area?   Would that tend to draw GPS
> navigation routes from nearby faster, parallel streets?


No.  What usually causes this is a regional speed limit where the local
speed is not yet known to OSM and/or priority signage hasn't been mapped
yet that obviate staying on the highway as the best route to the renderer
based on ground truth.


> Or would it
> look like an ugly gap in the trunk road if it switched to primary in
> that tourist area?
>

Depends on if you're rendering based on class or based on network.


>As an aside, I sense that the tendency to upgrade results in all OSM
> streets being promoted by one level, resulting in a compression at the
> top end and less class distinction at those levels.
>

This tends to be the case.  Seems like based on the AK2 conversation, this
is a prolific problem in northern Canada, where roads are uncommon in
general.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] algorithme de calcul de la clé - Re: ref:FR:FANTOIR

[Philippe Verdy]

>
>
> Avez-vous des communes avec dir ≠ 0 ?
>

Oui: toutes les communes des 4 départements 75, 92, 59 et 13.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Alaska Highway AK-2 tagging

[Paul Johnson]

On Mon, Dec 16, 2019 at 7:17 PM Eric H. Christensen  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, December 16, 2019 7:35 PM, Tod Fitch 
> wrote:
>
> > My reading of the wiki indicates that for the United States a trunk is
> “a high speed Arterial Divided highway that is partially grade separated.”
> [1]
> >
> > What is the problem with having the main road between
> regions/cities/towns being “primary”? Do you like the rendering of trunk
> better?
> >
> > For myself if I planned a driving trip and was expecting a trunk road
> I’d sure be surprised to find areas that are undivided and apparently, from
> other responses in this thread, unpaved in sections.
> >
> > [1]
> https://wiki.openstreetmap.org/wiki/United_States/Road_classification#Trunk
>
> I haven't seen that wiki page before.  Looking at the trunk page[0], the
> highway need not be divided and the U.S.-specific portion says "Surface
> expressway: A relatively high-speed divided road (at least 40 MPH with a
> barrier or median separating each direction of traffic), with a limited
> amount of intersections and driveways; or a major intercity highway. This
> includes many U.S. Highways (that do not parallel an Interstate) and some
> state highways.".  To me that meets the requirement for AK-2.
>

For a single carriageway road?  Seems like it's going the long way around
describing the southern loop of the Duncan Bypass
 or the entire
length of the Chicasaw Turnpike
.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Trunk VS primary,

[Mike N]

  I think many of the trunk VS motorway VS primary conflicts come from 
2 points of view:  on the one hand, people like to zoom out and see a 
coherent network of interconnected roads.   On the other side, there is 
the group that prefers the road be classed according to its regional 
characteristics, and not necessarily in the same class for its entire 
designated span.


On 12/16/2019 7:54 PM, Evin Fairchild wrote:
>Personally I think US highways should be tagged as trunk roads in most 
cases


  In the end, this would suffer from the same connectivity issue: 
should the US highway remain a trunk as it reduces to 2 lanes and drops 
to 30mph passing through a tourist area?   Would that tend to draw GPS 
navigation routes from nearby faster, parallel streets?  Or would it 
look like an ugly gap in the trunk road if it switched to primary in 
that tourist area?


  As an aside, I sense that the tendency to upgrade results in all OSM 
streets being promoted by one level, resulting in a compression at the 
top end and less class distinction at those levels.   But because of the 
subjective issues I just let it happen rather than re-edit any such 
changes unless they are massively changing everything in a region.



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

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

[Philippe Verdy]

Si on garde la clé c'est pour qu'elle soit vérifiable (et l'algo de calcul
est simplissime) et éviter les erreurs de saisie "à la volée". Ce qui
aurait mérité alors de garder le code division (là où il est encore utile
et non nul, donc pas dans les départements 75, 92, 59 et 13) : la
validation de la clé est alors immédiate et on repère immédiatement les
inversions de chiffres. Là on se contente juste d'un test de longueur, et
d'un controle à posteriori via le rapprochement BANO-OSM d'Osmose (ce qui
n'aide pas du tout les premiers contributeurs).

Ce serait donc bien de promouvoir ce contrôle à priori (dès la saisie ou
dans le validateur de données avant l'envoi à OSM) et non à posteriori
(d'autant qu'il y a encore des tas de lieux à référencer et rapprocher de
façon plus intelligente qu'un simple rapprochement de nom qui est bourré de
pièges). Ces références FANTOIR pourtant accélèrent considérablement à mon
avis les rapprochements et lèvent pas mal d'ambiguités, et fonctionnent
encore pour détecter les changements de noms et les expliquer.

Peut-être qu'on pourrait s'en sortir en délimitant les zones de direction
dans les 4 départements concernés, afin que la validation puisse déduire le
code manquant pour valider la clé. pour les autres départements on sait que
le code direction est 0, donc la validation est possible et à mon avis il
reste alors recommandé de garder la lettre clé finale dans les données OSM.

C'est une solution simple: 4 zones à créer pour Paris, 2 zones pour chacun
des 3 départements (à priori des communes entières, sauf si depuis des
communes ont fusionné entre deux zones à cheval, sans forcément changer les
codes FANTOIR qui risquent fort d'attendre encore 1 an ou plus avec leur
ancien code commune et leur ancien code direction).

Cela permettrait ensuite de faire le point avec la DGFIP pour que
finalement elle voit que les codes direction ne sont plus nécessaires et
peuvent être unifiés à "0" sans avoir même besoin de le préciser, quitte à
changer les lettres clés dans les 4 départements pour tenir compte du
changement implicite de code direction à 0, puis finalement même retirer ce
code direction obsolète du fichier FANTOIR de la DGFIP.

Et tant qu'à faire ce changement pour les 4 départements, rationaliser à
nouveau la typologie (les codes voie à 4 chiffres peuvent tous passer à 1
lettre plus 3 chiffres, puisque toutes les lettres ne sont pas utilisées).
LE code final en serait plus lisible sous la forme générale: 5 chiffres
(code commune)+1 lettre de type+3 chiffres (rang dans le type)+lettre clé
calculée sur les 9 premiers caractères (sans besoin de changer l'algo de
calcul qui reste simple: une substitution des lettres par un chiffres puis
un calcul similaire au LUHN, et un modulo mappé sur une lettre finale).

Ou bien tout en gardant 10 caractères, passer à un code avec  5 chiffres
(code commune)+2 lettres (type+sous-collection du type sans le 0, le I et
le L pour éviter la confusion avec les chiffres en ignorant la casse non
significative) +2 chiffres (rang dans le type+collection)+lettre clé (avec
un nouvel algo possible: une simple somme des chiffres, pondérés chacun par
plusieurs facteurs distincts 1,2,3,5,7,11,13,17,19 en fonction de leur
rang, puis un modulo égal à un autre nombre premier comme 23, conduisant à
mapper une clé d'une lettre parmi 23, sans le I et le O). Le sous-code
"collection" peut être utilisé pour les transitions millésimées dues aux
fusions/scissions de communes (on a le choix parmi les 23x23 lettres, quand
actuellement on n'utilise que les chiffres 00 à 99 et souvent beaucoup
moins, et 1 lettre parmi 3 suivi d'un chiffre parmi 9).

Au pire, on définit ça comme notre nouveau "code FANTOIR-OSM" remplaçant le
"code FANTOIR-RIVOLI" historique et capable aussi de représenter d'autres
champs du FANTOIR (exemple: public contre privé,
provisoire/chantier/projet/voie déclassée ou fermée mais qui pourrait être
reclassée à l'avenir). Et ce nouveau code n'a pas non plus obligation à
n'être que pour les communes si la compétence échoie à une agglomération ou
un département (dans ce cas on peut jouer sur les 5 premiers chiffres ou
lettres), ou à un grand gestionnaire foncier privé ou para-public (exemple:
agences de bassin, parcs naturels, portuaires/aéro-portuaire, armée,
forêts, zones internationales...)

Le lun. 16 déc. 2019 à 13:08, Vincent de Château-Thierry 
a écrit :

>
> > De: "Yves P." 
>
> > Concernant la clé de contrôle, est-ce nécessaire de la garder sachant
> > qu’il peut manquer le code div pour la recalculer ?
> > Si j’ai bien compris, tu as la base DGFiP complète sur un serveur et
> > un outil de contrôle qualité qui peut vérifier la cohérence entre
> > ref:FR:FANTOIR et les données brutes « FANTOIR ».
> > Du coup elle devient inutile ?
>
> Oui, le fichier FANTOIR est pris ici :
>
> https://www.data.gouv.fr/fr/datasets/fichier-fantoir-des-voies-et-lieux-dits/
> et fait partie intégrante du processus BANO, car cette longue liste est
> (sur le 

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

[Quentin Salles]

Bonjour deauzeffe,

Rassure-moi : les arrêts en question sont bien dans une relation (avec
les voies) ie un trajet, elle-même dans la relation globale qui regroupe
tous les trajets ?
Oui l'ensemble des lignes se trouvent dans une relation "network"

Et comme je disais, je souhaitais ce changement de tag car d'autres réseaux
l'ont fait. Après, je peux toujours faire un rétropédalage de la clé "ref"

Quentin SALLES

Le sam. 14 déc. 2019 à 11:43, deuzeffe  a écrit :

> Le 13/12/2019 à 18:13, Quentin Salles a écrit :
> > Bonsoir,
>
> Bonjour,
>
> > @deauzeffe Ce que tu dis est juste dans le cas où je cherche les arrêts
> > de bus pour une ligne donnée.
> > Or dans ce que je disais, ça concernait l'ensemble des arrêts desservis
> > par toutes les lignes du réseau Tisséo
>
> Rassure-moi : les arrêts en question sont bien dans une relation (avec
> les voies) ie un trajet, elle-même dans la relation globale qui regroupe
> tous les trajets ?
>
> Pour ce que j'ai fait pour le réseau STCLM, j'avoue avoir été fainéante
> et *ne pas avoir* taggué les références sur tous les arrêts.
> Ça peut se faire, c'est juste que même si c'est une "petite" CU, il y en
> a whamille. Sans compter qu'il y a des arrêts desservis par plusieurs
> réseau, et que oui, j'ai loupé cette étape. D'où ma préférence pour les
> relations.
>
> --
> deuzeffe - partisane de l'effort optimal
>
> > Quentin SALLES
> >
> > Le ven. 13 déc. 2019 à 17:55, laurent-38  > > a écrit :
> >
> > Frédéric Rodrigo-2 wrote
> >  > Le principe des règles, c'est de corrigé les données, pas les
> règles.
> >  > La règle est valide et basé sur le wiki OSM.
> >  >
> >  > Le 10/12/2019 à 14:48, Quentin Salles a écrit :
> >  >> …
> >  >> Aujourd'hui, Osmose
> >  >> signale tous les arrêts de bus ayant un mauvais suffixe
> > d'attribut sur
> >  >> la clé "ref:FR:Tisséo".
> >
> > Bonjour Frédéric,
> >
> > Peux-tu préciser le sens de ta réponse ?
> >
> > S’agit-il de supprimer les accents dans les clés tels que
> > ref:FR:Tisséo (ou
> > ref:Transisère) ? Le wiki ne me semble pas l’interdire :
> > https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Characters
> >
> > Ou bien s’agit-il d’enregistrer ces clés dans une « liste blanche »,
> > type
> >
> https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales
> ,
> > pour qu’elles soient considérées comme correctes ?
> >
> > Cordialement
> > ~~
> > laurent
> >
> >
> >
> > --
> > Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Alaska Highway AK-2 tagging

[Paul Johnson]

On Mon, Dec 16, 2019 at 10:29 PM Michael Patrick 
wrote:

>   > secondary in most cases for the state
>> highways and primary for the US ones.
>>
>
>  At least for the U.S., the Interstate vs. State Route distinction has
> more to do with funding than  carrying capacity and physical attributes. We
> have several State Routes that are definitely expressways:
> https://www.windy.com/-Webcams/United-States/Washington/Seattle/SR-at-MP-:-Des-Moines-Memorial-Dr/webcams/1459260132?47.545,-122.306,13
>

That looks more like a freeway (an expressway is a freeway with
intersections or a mix of ramps and intersections).


> Although they are few, there are still portions of the Interstate that are
> not expressways:
>
> https://en.wikipedia.org/wiki/List_of_gaps_in_Interstate_Highways#Undivided_and_narrow_freeways
>

Yeah, I 5 at either end past the last exit, for example.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Quentin Salles]

Bonjour,

Je compte faire un peu de mis à jour sur ma commune au niveau des adresses
et j'aimerai avoir des informations de votre part.
1/ Tout d'abord, le "ref:FR:FANTOIR" doit être placé au niveau du way ou de
la relation ?
2/ Que faire des voies qui ne comportent pas de rapprochement OSM/Cadastre
? http://cadastre.openstreetmap.fr/fantoir/#insee=31044=0
- Par exemple, sur le lien ci-dessus, "AV DU BICENTENAIRE 1789-1989" est
inscrit sur le fichier FANTOIR. Sur la commune, les plaques de rue
n'affiche que "AV DU BICENTENAIRE". Que faut-il choisir entre les 2 ?
- Que signifie "Ok" lorsqu'il n'y a pas de rapprochement avec OSM ?

Merci d'avance pour votre réponse.

Quentin

Le mar. 17 déc. 2019 à 12:14, Yves P.  a écrit :

> Bonjour,
>
> Suite du nettoyage.
>
> > Le 14 déc. 2019 à 12:37, Donat ROBAUX  a écrit :
>
> > */ref:FR:fantoir/. Sur celle de Brest, c'est le code voie qui est mis
> sur chaque adresse.
>
> J’ai regardé dans toutes les valeur de ref:FR:FANTOIR : il y en a 4395. On
> peut rajouter les 458 ref:FR:fantoir
>
> > ref:right:FR:FANTOIR doit être renommé en ref:FR:FANTOIR:right
> >
> > Ca j'ai corrigé
>
> Merci :)
>
> > Pour les /source:ref:fantoir/, je pense qu'on peut les enlever, ca
> n’apporte rien.
>
> C’est fait.
>
> —
> Yves
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali

[Martin Koppenhoefer]

Am Di., 17. Dez. 2019 um 11:05 Uhr schrieb Volker Schmidt :

> Aree pedonali con questo segno
>  sono aperte
> alle bici, se non c'è un cartello con divieto esplicito come in questo
> segno 
> Il secondo caso mi sembra chiaro:
>   highway=pedestrian e bicycle=dismount
> Il primo caso, è quello che mi interessa:
>   highway=pedestrian e bicycle=yes o bicycle=designated?
> Perché la domanda?
> Sotto l'aspetto legale un'Area Pedonale (in Italia - è diverso in altri
> paesi) ha le stesse restrizioni per bici di un percorso ciclo-pedonale
> condiviso (questo segnale
> ), cioè in
> entrambi i casi si tratta di un percorso pedonale, dove le biciclette sono
> "ospiti" dei pedoni, nel senso che pedoni hanno la precedenza fino al punto
> che i ciclisti devono condurre la bici a mano in caso che ci siano troppi
> pedoni.
> Finora la (mia) prassi è stata quella di taggare l'Area pedonale con
>highway=pedestrian e bicycle=yes
> è la ciclpedonale condivisa con
>hghway=path, foot=designated; bicycle=designated; segregated=no
> Il mio dubbio:
> Perché taggare de cose legalmente molto simili in modo diverso?
>



non so se esiste in Italia, un marciapiede con segno "libero per bici" (in
Germania: Fahrräder frei), solitamente viene taggato highway=footway,
bicycle=yes e le regole sono come nel tuo caso 1 (bici ospiti dei pedoni).

Non trovo differenza tra bicycle=no e bicycle=dismount, perché entrambi i
tags si riferiscono a biciclette, perché una bicicletta condotta a mano è
come una bottiglia d'acqua o un cappello rosso: non conta, si diventa
pedone a tutti gli effetti.

Quello che mi confonde: 2 segnali quasi uguali (pedone in cerchio blu)
hanno 2 significati molto diversi: se si tratta di una "zona" le bici
possono entrare, invece se si tratta di un altro tipo di percorso no?

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

[OSM-talk-fr] Orthos: mise à jour 2018 sur de nombreux départements

[Christian Quest]

La liste: 04 11 30 54 55 57 60 66 67 71 84 88 89

L'Oise (60) est disponible pour la première fois en opendata, ainsi que le
71 et 89 (depuis déjà plusieurs mois).

Tout ça est intégré dans 3 couches:
- orthohr_2018 : qui ne contient que les orthos de 2018
- orthohr : qui contient toutes les orthohr
- tous_fr : qui est combinaisons de toutes les orthos, en priorisant la
date puis la résolution

Vous avez le détail sur le wiki:
https://wiki.openstreetmap.org/wiki/FR:Serveurs/wms.openstreetmap.fr

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

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

[Yves P.]

Bonjour,

Suite du nettoyage.

> Le 14 déc. 2019 à 12:37, Donat ROBAUX  a écrit :

> */ref:FR:fantoir/. Sur celle de Brest, c'est le code voie qui est mis sur 
> chaque adresse.

J’ai regardé dans toutes les valeur de ref:FR:FANTOIR : il y en a 4395. On peut 
rajouter les 458 ref:FR:fantoir

> ref:right:FR:FANTOIR doit être renommé en ref:FR:FANTOIR:right
> 
> Ca j'ai corrigé

Merci :)

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

C’est fait.

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

Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali

[Volker Schmidt]

On Tue, 17 Dec 2019 at 11:24, Alessandro Sarretta <
alessandro.sarre...@gmail.com> wrote:

> Anche se legislativamente probabilmente le due
> situazioni si equivalgono, mi pare che assegnare bicycle=yes nelle aree
> pedonali e bycicle=designated nelle ciclopedonali condivise descriva più
> correttamente il livello di priorità pedonale nelle due situazioni.
>
Non penso che ci sia nessuna differenza in questo rispetto.

>
> Non so quanto queste "sottigliezze" vengano considerate da algoritmi di
> routing o nella produzione di mappe, però mi sembra una buona pratica da
> mantenere.
>
Non lo so neanche io. Mi è venuto il dubbio esattamente per questo: un
router vede "pedonale" e ti da una enorme penalty per spingere la bici a
piedi.
Se vede "bicycle=designated", forse non lo fa.
Come sai sto lavorando su la mappa ciclabile di Padova e vengono a galla
tutte le varianti possibili di tagging (in una sola città!) - un vero
lavoraccio. E non penso che ci sia un router le "conosca" tutte.

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

Re: [talk-au] Are we allowed to use PTV datasets (CC 4.0)?

[Aaron]

Hi everyone,

Just as an update, in case anyone is thinking of sending off another
waiver. I got a reply back from the DPC. They've found the correct person
to look at the request, and are awaiting their response.

Cheers!

On Wed, Nov 20, 2019 at 4:22 PM Aaron  wrote:

> Thank you for the information. I've included the original email below, and
> I've attached the waiver.
>
> *Original message:*
> From: Aaron Fang Shenhao 
> Date: Wed, 18 Sep 2019 at 1:54 am
> Subject: Permission to Incorporate PTV's CC BY Data Into OpenStreetMap
> To: 
>
> Dear Department of Premier and Cabinet,
>
> Thank you for making Public Transport Victoria’s open data available under
> the Creative Commons CC BY 4.0 license at data.vic.gov.au.
>
> I am a volunteer of OpenStreetMap , a
> collaborative open project to create a global geodata set freely usable by
> anyone on share-alike and attribution terms under the Open Database
> License (ODbL) .
>
> We’re very interested in using the data in Public Transport Victoria’s
> open data to improve OpenStreetMap. In order to facilitate this, we need
> to confirm with you that Public Transport Victoria has no objections.
>
> In particular, there are two issues we would like to clarify.
>
> First, because OpenStreetMap's data comes from thousands of local
> volunteers as well as numerous government sources, attribution to all such
> sources on an OpenStreetMap-based map or similar visual display is
> impossible. Instead, we provide attribution (including original license
> information) to major sources like Public Transport Victoria on our 
> Contributors
> page .
> OpenStreetMap users are then required to attribute "OpenStreetMap
> Contributors" in a collective fashion
>  when using any OpenStreetMap
> data. CC BY's attribution requirements are relatively general, so we just
> need you to confirm that you would consider OpenStreetMap's attribution
> method to attribute Public Transport Victoria in a "reasonable manner" in
> accordance with Section 3(a)(1) of the CC BY 4.0 license.
>
> Second, the ODbL and CC BY 4.0 have slightly different ways of addressing
> digital rights management technologies. The ODbL allows data users to apply
> technical protection measures to their own works so long as they also
> provide an unrestricted version of the underlying database, including their
> own additions ("parallel distribution"). In contrast, CC BY 4.0 can be read
> to prohibit any application of technical protection measures to databases
> that include CC BY material. This is a relatively minor difference in how
> the licenses are drafted, but means that in some cases, users who comply
> with ODbL might not comply with CC BY 4.0.
>
> In practice, we have found that parallel distribution is an excellent way
> of ensuring open access to data while allowing flexibility in use. Thus, we
> ask that, to the extent CC BY 4.0 Section 2(a)(5)(B) prohibits any
> downstream restrictions even when parallel distribution is available, you
> waive this license restriction as to OSM and its users. This waiver would
> have no effect on Public Transport Victoria’s original dataset and only
> pertains to the restrictions allowed on combinations of that data with OSM
> data.
>
> Thank you for your consideration. If Public Transport Victoria is
> amenable, can you please check off the boxes in the attached form and
> return a signed version to me?
>
> If you have any questions or would like more information about
> OpenStreetMap, please do not hesitate to contact me by e-mail.
>
> Regards,
>
> Aaron Fang Shenhao
>
> Local OSM Representative
>
> http://www.openstreetmap.org
>
> http://localosmgroup.tld
>
> On Wed, 20 Nov 2019 at 4:14 pm, Andrew Harvey 
> wrote:
>
>> Unfortunately it is quite common to not hear back. Which email did you
>> send to? It's worth sending a reminder email.
>>
>>
>> On Wed., 20 Nov. 2019, 11:58 am Aaron, 
>> wrote:
>>
>>> Hi,
>>>
>>> Just checking up on this. It's been 2 months since I sent the waiver, is
>>> it a normal waiting period, or did I address the wrong person or something?
>>> :P
>>>
>>> Thanks,
>>> Aaron.
>>>
>>> On Sun, 15 Sep 2019 at 4:39 pm, Sebastian S.  wrote:
>>>
 Hi and also welcome,
 It would be good if you update the wiki once you've sent the waiver
 request off.
 This helps tracking what's going on.

 Cheers,
 Seb

 --
 Sent from my Android device with K-9 Mail. Please excuse my brevity.

 On 14 September 2019 10:01:34 pm AEST, Aaron Fang Shenhao <
 aaronshenhao2...@gmail.com> wrote:
>
> Thank you both for the helpful info!
>
> I'll get onto sending the waiver letter to PTV. Once it comes back
> I'll make sure to update the wiki and report back.
>
> I've summarised the number of stops and routes in 

Re: [Talk-it] [talk-it] tagging accesso bici in Aree Pedonali

[Alessandro Sarretta]

Ciao Volker,

On 17/12/19 11:04, Volker Schmidt wrote:

Finora la (mia) prassi è stata quella di taggare l'Area pedonale con
highway=pedestrian e bicycle=yes
è la ciclpedonale condivisa con
   hghway=path, foot=designated; bicycle=designated; segregated=no
Il mio dubbio:
Perché taggare de cose legalmente molto simili in modo diverso?

Opinioni?


non sono un esperto in materia, ma personalmente condivido la tua 
modalità di tagging. Anche se legislativamente probabilmente le due 
situazioni si equivalgono, mi pare che assegnare bicycle=yes nelle aree 
pedonali e bycicle=designated nelle ciclopedonali condivise descriva più 
correttamente il livello di priorità pedonale nelle due situazioni.


Non so quanto queste "sottigliezze" vengano considerate da algoritmi di 
routing o nella produzione di mappe, però mi sembra una buona pratica da 
mantenere.


Ale


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

[Talk-it] [talk-it] tagging accesso bici in Aree Pedonali

[Volker Schmidt]

Aree pedonali con questo segno
 sono aperte alle
bici, se non c'è un cartello con divieto esplicito come in questo segno

Il secondo caso mi sembra chiaro:
  highway=pedestrian e bicycle=dismount
Il primo caso, è quello che mi interessa:
  highway=pedestrian e bicycle=yes o bicycle=designated?
Perché la domanda?
Sotto l'aspetto legale un'Area Pedonale (in Italia - è diverso in altri
paesi) ha le stesse restrizioni per bici di un percorso ciclo-pedonale
condiviso (questo segnale
), cioè in
entrambi i casi si tratta di un percorso pedonale, dove le biciclette sono
"ospiti" dei pedoni, nel senso che pedoni hanno la precedenza fino al punto
che i ciclisti devono condurre la bici a mano in caso che ci siano troppi
pedoni.
Finora la (mia) prassi è stata quella di taggare l'Area pedonale con
   highway=pedestrian e bicycle=yes
è la ciclpedonale condivisa con
   hghway=path, foot=designated; bicycle=designated; segregated=no
Il mio dubbio:
Perché taggare de cose legalmente molto simili in modo diverso?

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

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

[Philippe Verdy]

Les limites de tonnage variables selon le sens sont probablement erronées
(sauf en cas de tabliers séparés sur les ponts, mais alors on a deux ways
et non un seul. Sur les routes même avec des accotements déstabilisés, je
vois mal une mairie ou un département prendre le risque d'un dépassement
(parfois inévitable en cas d'obstruction) sur l'autre côté de la route
causant un effondrement ou un affaissement sans prévoir alors une
séparation des voies.

En revanche les limites de hauteur selon le côté de la route sont possibles
si le tablier au dessus traverse en oblique ou s'il y a des éléments
suspendus d'un seul côté. De même les restrictions de largeur en cas de
chaussées séparées 2+1 (le sens à 1 voie pouvant être trop étroit alors que
le sens à 2 voies peut encore permettre un passage même en occupant une
partie de la seconde voie).

Ca c'est la théorie, reste à voir si ça se trouve réellement (les voies 2+1
sont de plus en plus rares, remplacées par 1+1 voie et une bande centrale
étroite de chaque côté permettant juste un écart exceptionnel à vitesse
réduite, juste condamnée par un zébrage, ou réutilisée pour créer une bande
cyclable centrale à double sens ou une bande latérale dans chaque sens, ou
une réserve pour la sécurité des piétons.passant un tunnel sous un pont.

Mais la cartographie est pleine d'exceptions locales à ce qui semblerait
être la "norme"...


Le mar. 17 déc. 2019 à 10:34, Eric SIBERT via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> >> - restriction dans un seul sens?
> >
> > En ajoutant une flèche sur le halo rouge ?
>
> Non car je vois venir le cas de restrictions différentes dans les deux
> sens ;-)
> 10 T à la montée, 3,5T à la descente...
>
> Une flèche derrière le panneau?
>
> Eric
>
>
> ___
> 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] Rendu transport routier...

[Christian Quest]

Petit bug de ma part... je vais corriger ça ;)


Le mar. 17 déc. 2019 à 10:32, Donat ROBAUX  a écrit :

> Bon le message est parti un peu vite...
>
> Pour le pont de Châtillon-Montouge, les données sont bonnes et conformes au
> wiki avec le séparateur qui doit être un point.
> Donc il y a un bug dans la retranscription de la donnée.
> Idem ici, c'est encore plus flagrant avec 2 valeurs 5.07 et 4.57m qui
> apparaissent en 57m et 4.57m:
> http://osm.cquest.org/fortissimo/#18/48.81966/2.29577
>
> Donat
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] SPAM, Re: SPAM, Re: Nommage des bâtiments scolaires / universitaires complexes

[Vincent Bergeot]

Le 17/12/2019 à 08:00, Arnaud Champollion a écrit :

Le 17/12/2019 à 06:19, Vincent Bergeot a écrit :
j'aime landuse=school (pour l'ensemble scolaire) mais l'usage semble 
aller vers amenity=school, building=school et j'ajoute des poi pour 
amenity=school et school:FR=*, car même si maternelle et élémentaire 
sont dans un même lieu, c'est souvent distinct (entrée différente, 
cours de récréation et jeux adaptés, ...)


avec des redondances (ref uai, adresse, ...) 


Mais du coup ça crée plusieurs amenity=school pour une seule entité.

Si par exemple on fait une requête overpass (par exemple pour obtenir 
les écoles du département et les afficher sur Umap) on ne risque pas 
de se retrouver avec des doublons ?


oui et cela dépendra de la requête, du type d'écoles attendues. school, 
school:FR, ...


[amenity=school][school:FR=élémentaire] ne renvoie normalement pas de 
doublons dans le cas évoqué


De plus comme le précise @cquest par ailleurs, landuse=school est un peu 
franco-français, voire franco-allemande j'ai l'impression : 
https://taginfo.openstreetmap.org/tags/landuse=school#map


à plus


--
Vincent Bergeot


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

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

[Eric SIBERT via Talk-fr]

- restriction dans un seul sens?


En ajoutant une flèche sur le halo rouge ?


Non car je vois venir le cas de restrictions différentes dans les deux 
sens ;-)

10 T à la montée, 3,5T à la descente...

Une flèche derrière le panneau?

Eric


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

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

[Donat ROBAUX]

Bon le message est parti un peu vite...

Pour le pont de Châtillon-Montouge, les données sont bonnes et conformes au
wiki avec le séparateur qui doit être un point.
Donc il y a un bug dans la retranscription de la donnée.
Idem ici, c'est encore plus flagrant avec 2 valeurs 5.07 et 4.57m qui
apparaissent en 57m et 4.57m:
http://osm.cquest.org/fortissimo/#18/48.81966/2.29577

Donat



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

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

[Francescu GAROBY]

65m. de haut ? Ah oui, c'est bien : vous prévoyez large, par chez vous !

Le mar. 17 déc. 2019 à 10:21, Donat ROBAUX  a écrit :

> Pour la bizarrerie, je n'ai pas eu besoin d'aller loin de chez moi.
> http://osm.cquest.org/fortissimo/#17/48.81215/2.30086
>
> Mais que fait OSMontrouge?
>
> Donat
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

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

[Donat ROBAUX]

Pour la bizarrerie, je n'ai pas eu besoin d'aller loin de chez moi.
http://osm.cquest.org/fortissimo/#17/48.81215/2.30086

Mais que fait OSMontrouge? 

Donat



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

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

[Christian Quest]

Le lun. 16 déc. 2019 à 19:45, Eric SIBERT  a
écrit :

> Je viens de regarder. Quelques remarques:
> - maxwidth/maxheight : on ne voit pas bien les petites pointes autour de
> la valeur et on a du mal à distinguer les deux limitations.
>

Je vais améliorer les SVG des panneaux pour que ça soit plus visible.


> - double-restriction (maxweight = 3.5 et maxwidth = 2.2 par exemple). On
> ne voit que le maxweight.
>

Oui, ça, difficile à gérer sur le rendu, il faudrait des panneaux côte à
côté... pas simple au niveau cartocss.


> - restriction dans un seul sens? (la côte de Laffrey :
>
https://www.openstreetmap.org/#map=15/45.0344/5.7682
> https://fr.wikipedia.org/wiki/Rampe_de_Laffrey )
>
>
En ajoutant une flèche sur le halo rouge ?



> > Je découvre du coup de valeurs pas très catholiques dans ces tags !
>
> Des exemples, des exemples !!!
>
>
J'ai trouvé des valeurs multiples (avec ;), des valeurs en "4.00" (que je
nettoie), des unités présentes alors qu'on est en métrique, des valeurs
textuelles (filtrées), etc...


> Comme quoi, dès qu'on rend visible certaines données OSM...
>
> On ne taggue pas pour le rendu... mais ça aide ;-).
>
> Eric
>

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

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

[Christian Quest]

Hum... l'idée est de qualifier les voies visibles sur le fond. C'est au
fond de montrer que c'est en souterrain.

Au final, ces voies (en souterrain ou pas) ont des restrictions de
gabarits... ce qu'on montre avec l'overlay.

Le lun. 16 déc. 2019 à 17:59, Francescu GAROBY  a
écrit :

> Beau boulot !
> Une petite suggestion, tout de même : différencier les limitations de
> hauteur en surface, et celles en sous-sol.
> Exemple ici  : la
> limitation à 2,2m de haut concerne le parking souterrain du Leclerc.
>
>
> Francescu
>
> Le sam. 14 déc. 2019 à 18:30, Christian Quest  a
> écrit :
>
>> Je travaille depuis quelques temps sur un rendu destiné au transport
>> routier.
>>
>> Je finalise une couche en overlay qui rend visible les restrictions:
>> - maxheight
>> - maxweight
>> - maxwidth
>> - hgv/goods
>> - hazmat
>>
>> Voici ce que ça donne:
>> http://osm.cquest.org/fortissimo/#15/48.8324/2.3837
>>
>> Je découvre du coup de valeurs pas très catholiques dans ces tags !
>> Comme quoi, dès qu'on rend visible certaines données OSM...
>>
>> Le fond est une variation du style pianoforte (de ybon) qui comporte plus
>> d'éléments visibles et fait ressortir aussi les zones industrielles,
>> commerciales, chantiers. Son petit nom: fortissimo
>>
>> Merci pour vos retours !
>> --
>> Christian Quest - OpenStreetMap France
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Francescu
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Re: Nommage des bâtiments scolaires / universitaires complexes

[Christian Quest]

Attention, landuse=school est une bizarerie franco-française qui nous a
servit à décrire les groupes scolaires où l'on est incapable de dire quelle
partie correspond à quelle école (maternelle, élémentaire, etc).

Il est rendu sur le rendu FR, mais pas ailleurs à ce que je sache.


Le lun. 16 déc. 2019 à 04:58, Adrien André via Talk-fr <
talk-fr@openstreetmap.org> a écrit :

> Le 19-12-15 à 09 h 18, Adrien André via Talk-fr a écrit :
> > À ce sujet, j'ai remarqué qu'osm-carto ne rend pas les polygones
> > landuse=school.
> Par exemple, https://www.openstreetmap.org/way/687225350
>

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