Re: [Talk-it] fontanella a volte chiusa

2017-08-30 Per discussione scratera
...di fontanelle chiuse in questo periodo se ne trovano a bizzeffe...che
facciamo le modifichiamo tutte?



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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


Re: [Talk-it] fontanella a volte chiusa

2017-08-30 Per discussione scratera
...di fontanelle chiuse in questo periodo se ne trovano a bizzeffeche
facciamo le modifichiamo tutte?



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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


Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

2017-08-30 Per discussione Jérôme Amagat
oups
quand j'ai écrit "ça se fait quelque chose comme ça" j'ai oublier le "?"
parce que c'est une question.

Le 31 août 2017 à 01:21, Jérôme Amagat  a écrit :

> Pour faire les modifications sur les numéros
> ça se fait quelque chose comme ça (ici c'est pour passer de 04 à
> +334 avec X un chiffre) :
> avec overpass-turbo.eu et :
>
> [out:xml][timeout:2500];
> (
>   node["phone"~"^04[0-9]{8}$"]({{bbox}});
>   way["phone"~"^04[0-9]{8}$"]({{bbox}});
>   relation["phone"~"^04[0-9]{8}$"]({{bbox}});
> );
> out meta;
>
> on exporte données brutes depuis l'API Overpass
>
>
> on ouvre le fichier avec un éditeur de texte et avec l'option rechercher
> et remplacer on fait :
> rechercher :  que l'objet a été modifié il faut action="modify" dans la ligne :
>  user="">
> ( ou  ou
> )
>
> Donc un 2eme rechercher et remplacer avec par exemple :
> rechercher :  changeset="
> remplacer :  action="modify" changeset="
>
> Après on renomme le fichier interpreter avec .osm et on l'ouvre avec josm
> et on envoie les modifications.
>
> J'ai testé et je l'ai fait sur une petite surface (68 objets modifiés) :
> https://www.openstreetmap.org/changeset/51596881
>
> là c'est pour changer les numéro 04 en +334 avec X un
> chiffre
> on peut faire la même chose en changeant le regex (ici ça "^04[0-9]{8}$")
> dans overpass pour passer de 04 XX XX XX XX en +33 4 XX XX XX XX et pareil
> avec autre chose que les 04 , les fax ...
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

2017-08-30 Per discussione Jérôme Amagat
Pour faire les modifications sur les numéros
ça se fait quelque chose comme ça (ici c'est pour passer de 04 à
+334 avec X un chiffre) :
avec overpass-turbo.eu et :

[out:xml][timeout:2500];
(
  node["phone"~"^04[0-9]{8}$"]({{bbox}});
  way["phone"~"^04[0-9]{8}$"]({{bbox}});
  relation["phone"~"^04[0-9]{8}$"]({{bbox}});
);
out meta;

on exporte données brutes depuis l'API Overpass


on ouvre le fichier avec un éditeur de texte et avec l'option rechercher et
remplacer on fait :
rechercher : 
( ou  ou
)

Donc un 2eme rechercher et remplacer avec par exemple :
rechercher :  changeset="
remplacer :  action="modify" changeset="

Après on renomme le fichier interpreter avec .osm et on l'ouvre avec josm
et on envoie les modifications.

J'ai testé et je l'ai fait sur une petite surface (68 objets modifiés) :
https://www.openstreetmap.org/changeset/51596881

là c'est pour changer les numéro 04 en +334 avec X un
chiffre
on peut faire la même chose en changeant le regex (ici ça "^04[0-9]{8}$")
dans overpass pour passer de 04 XX XX XX XX en +33 4 XX XX XX XX et pareil
avec autre chose que les 04 , les fax ...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-br] Mapeamento hidrológico

2017-08-30 Per discussione Sérgio V .
Não sei.

Destas 2 que apontaste, são sugestões? Tens alguma ideia de preferência, prós e 
contras?


A princípio imagino que deveria poder ser mapeada do mesmo modo como é 
convencionalmente mapeada uma bacia no papel: rio principal, rios tributários, 
áreas, micro-bacias,...


Por enquanto só tenho a ideia de que seria bom que a bacia constasse de algum 
modo em algum tipo de relação com o seu waterway principal (mainstream). Tipo, 
"Rio Uruguai" /  "Bacia Hidrográfica do Rio Uruguai".


Atualmente funciona só pra relação de "Rios": 
https://wiki.openstreetmap.org/wiki/Relation:waterway

(Inicialmente penso que deveria ser propriamente uma relação de "bacia", não 
criar mais um tipo de relação paralela)


Relação "Rio Uruguai ": http://www.openstreetmap.org/relation/380835

Membros:

1) main_stream: trecho1,trecho2,trecho3,(do Rio Uruguay)...

2) side_stream : 1,2,3,(do Rio Uruguay)...

(side_stream não serve pra tributários, apenas para desvios e retornos: "a 
branch of main stream that returns to it".)


Tinha que ter algo que pudesse colocar ainda na mesma relação:


3) todos os tributários: ex. , desde o Rio Pelotas, Rio Canoas, até o Rio 
Quaraí, etc:

http://www.openstreetmap.org/way/40834616
Juntos, formando uma "rede", tipo network, ou sei lá.

Como existe a "Key:network", mas esta (infelizmente, atualmente) é só para 
"rotas terrestres", highway: https://wiki.openstreetmap.org/wiki/Key:network.

Por sinal, ao inventarem esta tag, deste modo, me parece que criaram um 
problema de conceito, como se "rede" fosse só de vias terrestres (mas o OSM não 
é só pra carros).

A rede que forma a reunião de todos os tributários + o Rio Uruguay, constitui a 
bacia.

Não entendo muito da relação de rede de Strahler, mas parece que poderia ser 
por aí, o esquema surgiu justamente na hidrologia para isso.


Assim, ainda teria que fazer parte da mesma relação:

4) a bacia mesma, ex. "Bacia Hidrográfica do Rio Uruguai": uma área, portanto 
(365.000 km²:  https://pt.wikipedia.org/wiki/Bacia_do_rio_Uruguai)

Os limites poderiam ser mapeados de modo semelhante a limites administrativos, 
podendo envolver trechos de "ridge" (divisor de águas), p.ex.


Tudo numa única relação. A relação, penso, deveria mesmo levar o nome de "bacia 
tal" (não se restringir a uma relação de waterways, o curso); não Relação "Rio 
Uruguai",  mas "Bacia do Rio Uruguai" (ou "Bacia Hidrográfica do Rio Uruguai").


Imagino que deveria ser mais ou menos assim, tal como é o mapeamento 
convencional em geografia, hidrologia...

https://en.wikipedia.org/wiki/Drainage_basin

https://en.wikipedia.org/wiki/Main_stem

https://en.wikipedia.org/wiki/Strahler_number#River_networks


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: santamariense 
Enviado: quarta-feira, 30 de agosto de 2017 10:00
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Mapeamento hidrológico

Qual a ideia de como mapear Bacias Hidrográficas? Criando relação e
adicionando os respectivos waterways? Ou adicionando tags do tipo
estánabacia="Bacia Hidrográfica do Aa" em cada waterway?

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


Re: [OSM-talk-fr] Champs phone : numéros courts, Wikipédia etc..

2017-08-30 Per discussione Philippe Verdy
Le 30 août 2017 à 23:11,  a écrit :

> Le 30/08/2017 à 03:49, Francois Gouget - fgou...@free.fr a écrit :
> Ça dit que si tu composes le 196, tu obtiendras un Centre régional
> opérationnel de surveillance et de sauvetage
> ,
> le plus proche de la position estimée de ton téléphone. Par exemple avec un
> 02 90 (valable pour un des 4 départements de la région administrative
> Bretagne) tomberas-tu sur le CROSS Corsen ou le CROSS Etel ou un autre ?
> Aucune idée. Idem en appelant depuis un 08 70 ou un 09 : je ne connais la
> précision de leur outil de choix.
> Mais c'est comme si tu appelles le 112 depuis un mobile : tu peux tomber
> sur le département d'à côté, ils passeront à la bonne structure.
>

Cela ne dépend pas du tout des services que tu veux appeler, mais de ton
opérateur selon la façon dont il route tes propres appels depuis ta ligne
(que ce soit une ligne fixe 01-05, une box internet 0870, ou une ligne
mobile 06/07). C'est ton opérateur par lequel tu es connecté qui détermine
vers quel service d'urgence il va router les numéros courts selon les
accords qu'il a avec ces services à qui il transmet ton numéro réel (par
lequel le service d'urgence pourra te rappeler directement), même si tu
appelles avec la fonction de masquage et que ton téléphone est en liste
rouge ou n'a pas lui-même de numéro public permettant de te joindre sur le
même poste.

Si ton opérateur est mobile, il détermine la structure locale à joindre
selon l'antenne mobile sur laquelle ton téléphone s'est accroché,
l'opérateur n'a pas besoin de connaitre ta position réelle. Si ton
opérateur est celui d'une ligne fixe (cuivre, cable ou fibre), l'opérateur
connait l'adresse de ton installation et t'a inscrit dans une zone de
localisation contenant les règles de routage des numéros d'urgence
appropriés pour toute ta zone mais en général il suffit pour lui d'avoir
inscrit sur ta ligne le code INSEE de ta commune et ça suffit pour que ton
appel aille vers le service local d'urgence le plus proche)

Pour le reste, si le service local est surchargé ou injoignable, il y a des
règles prédéfinies par les SDIS, les préfectures et les ministères, leur
permettant d'indiquer à l'opérateur un autre acheminement vers d'autres
service plus loin ou vers une plateforme nationale de secours (telle que
celle d'Asnières-sur-Seine qui peut se coordonner avec les services de
secours de n'importe de quelle région et qui dispose de relais par
satellite et d'un centre d'appel capable de traiter des milliers d'appels
et les rerouter vers d'autres services), et si nécessaire en passant par
n'importe quel autre opérateur ou liaison hertzienne ayant de la capacité
disponible, ou même par une demande des autorités permettant de réduire la
bande passante des autres services (y compris sur des réseaux privés, ou
des fréquences non utilisées par les radiodiffuseurs) pour pouvoir
acheminer les appels prioritaires (à commencer par le 112).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

2017-08-30 Per discussione Philippe Verdy
Le 30 août 2017 à 22:52,  a écrit :

> Le 30/08/2017 à 11:42, JB - jb...@mailoo.org a écrit :
> Après formater en un bloc pour les numéros courts, en 0X[ XX]+ pour les
> autres nationaux (si actuellement présentés en un paquet), en +33 X[ XX]+
> pour les internationaux (là si actuellement présentés en un paquet ou +33 +
> paquet). Sinon transformer en gardant la trame de base (style 0100 200 300
> devenant +33 100 200 300).
>

D'accord si on garde au minimum cette trame avec des groupes de 2 ou 3 ou 4
chiffres après le 0 ou +33 initial (détaché du reste avec une seule
espace). Des groupes à 4 chiffres à la fin sont également mnémoniques
(exemple avec 01 45 24 7000 pour Radio France, c'et comme ça que c'est
prononcé à l'antenne). Les groupements variables peuvent aussi éviter des
prononciations ambiguës si on les place correctement ("0 23 100 2000" ou "0
20 300 2000" ?) mais ça ne change rien au fait de remplacer le 0 initial
quand il n'y a que 9 chiffres après. Les séparateurs peuvent être gardés à
leur place, mais unifiés vers l'espace.

Note: les PABX privés ne nécessitent pas tous un délai. Les grosses
entreprises qui ont leur propre bloc de numéros alloué par l'ARCEP
fonctionnent directement sans aucune pause avec le numéro complet. On en a
une liste sur le site de l'ARCEP, et ces blocs sont gérés de la même
manière que les blocs attribués aux opérateurs grand public (ceux-ci
supportant toutefois la "portabilité" des numéros qui n'est pas imposée aux
entreprises qui ont leur propres blocs de numéro alloué. Le délai n'est
imposé que si le PABX ne dispose pas de la fonctionnalité "SDA" (qui
existait depuis le milieu des années 1980 en France alors que France
Telecom était encore un monopole...).

Ca fait partie du protocole standard de signalisation dit "numéro 7"
(normalisé depuis les années 1970, mais arrivé en France avec le
déploiement du RNIS et des lignes de type "T0" ou "T1" au lieux des
classiques lignes groupées "S0").

La SDA est toujours fonctionnelle et est très utilisée (elle l'a été
beaucoup plus au temps où on utilisait beaucoup les fax pour distinguer un
appel vocal d'un appel fax avec un chiffre supplémentaire de SDA). Aussi on
trouve encore des numéros de fax à 11 chiffres (et aucune attente
nécessaire après les 10 premiers chiffres, et bien au contraire il n'en
faut pas, on compose directement le numéro complet pour éviter le routage
vers un poste vocal et des numéros de service évitant de passer par un
serveur vocal quand on veut un service précis directement (par exemple un
service client, le service facturation, un service conseil aux entreprises,
un service de réservation, et si on ne compose pas ce chiffre le renvoi
vers le standard peut vous faire attendre de longues minutes avant d'être
mis en relation, le temps que quelqu'un soit disponible pour répondre ! Le
numéro SDA est reçu directement avec le numéro complet demandé, avant même
de "décrocher" pour répondre à l'appelant.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Champs phone : numéros courts, Wikipédia etc..

2017-08-30 Per discussione osm . sanspourriel

Le 30/08/2017 à 03:49, Francois Gouget - fgou...@free.fr a écrit :


Reste à prendre une décision pour les 3631...

(...)

Cela dit je n'ai jamais appelé le 3631 donc je me fait peut-être des
idées sur leur service.
Moi j'ai voulu contacter un bureau de la Poste en particulier mais pas 
le plus proche et avec le 3631, j'avais l'air d'un con. C'est un numéro 
surtaxé sans valeur ajoutée ;-)

On a un peu le même problème avec les tags wikipedia (et wikidata). Par
exemple j'ai hérité d'un signalement Osmose qui me dit que le tag
wikipedia=fr:Crédit agricole est en doublon sur une des agences.
Logique.

Mais j'en conclu que dès qu'il s'agit d'une 'chaîne' (de restaurants, de
magasins, d'agences bancaires) le tag wikipedia ne sert strictement à
rien :
  * Impossible de le mettre sur une agence : pourquoi le mettre sur
l'une et pas sur les autres ?
Tu dois mettre dans ce cas operator 
:*wikipedia* pas 
wikipedia. Et par analogie, je propose operator:phone:FR=3631

Simple, logique, cohérent.

Mais c'est sûr que ça fait beaucoup d'informations dupliquées.

Ce n'est pas seulement dupliqué, c'est faux.
OSM c'est de la représentation géolocalisée.
Les informations non localisées sont à proscrire sauf s'il est clair 
qu'elles le sont : l'article Wikipedia doit parler de ce restaurant en 
particulier, operator:wikipedia parle de la chaîne en particulier.


operator:phone:FR=196 pour les CROSS, ça me va.
Ça dit que si tu composes le 196, tu obtiendras un Centre régional 
opérationnel de surveillance et de sauvetage 
, 
le plus proche de la position estimée de ton téléphone. Par exemple avec 
un 02 90 (valable pour un des 4 départements de la région administrative 
Bretagne) tomberas-tu sur le CROSS Corsen ou le CROSS Etel ou un autre 
?  Aucune idée. Idem en appelant depuis un 08 70 ou un 09 : je ne 
connais la précision de leur outil de choix.
Mais c'est comme si tu appelles le 112 depuis un mobile : tu peux tomber 
sur le département d'à côté, ils passeront à la bonne structure.
Donc je propose operator:phone:FR pour les numéros dont le destinataire 
dépend du lieu estimé de l'appelant.


Jean-Yvon

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


Re: [Talk-cz] Ilegální pěšiny v lese?

2017-08-30 Per discussione Marián Kyral
Dne 30.8.2017 v 22:32 Marián Kyral napsal(a):
> Dne 28.8.2017 v 22:03 Pavel Machek napsal(a):
>> AhoJ!
>>
>>> v karlovarském kraji se objevil nový uživatel, který maže "Ilegální" pěšiny
>>> na pozemcích "Náboženská matice".
>>>
>>> https://www.openstreetmap.org/user/Radek%20Broz/history
>>>
>>> Co s ním?
>> Revertovat, a reportovat na data working group.
>>
>> a) chodit po lese je legalni
>>
>> i kdyby nahodou nebylo
>>
>> b) mapujem realitu
>>  Pavel
> Pán mi na komentář k changesetu neodpověděl, revertoval jsem:
> http://www.openstreetmap.org/changeset/51593471
> http://www.openstreetmap.org/changeset/51593299
>
> Ještě mu pošlu zprávu, kde se mu to pokusím vysvětlit.

…trochu jsem se rozepsal, snad ta nemám nějaké chyby a nesprávná tvrzení:

> /Dobrý den,//
> //protože jste mi neodpověděl na komentář u sady změn
> https://www.openstreetmap.org/changeset/51429784 , byly vaše editace
> vyhodnoceny aktivní českou komunitou vyhodnoceny jako vandalismus a
> revertovány (zrušeny).//
> / /
> //Důvody://
> //V ČR neexistuje nic jako "nelegální" pěšina v lese. Maximálně tak
> pěšina lesem, kde je zákaz vstupu. Ale to jsou v ČR jen některé
> případy, jako I. zóny národních parků, vojenské prostory a ohrazené
> lesy (obory), kde je zákaz vstupu. Ale i tam je možno tyto pěšiny (a
> cesty) mapovat. Jen je na nich vyznačen zákaz vstupu.//
> / /
> //OpenStreetMap se drží zásady, že se mapuje to, co je na zemi
> viditelné - je ověřitelné v terénu dalšími mapery. Viz:
> https://wiki.openstreetmap.org/wiki/Cs:Jak_mapujeme//
> / /
> //Vámi smazané pěšiny v terénu existují, což mimo jiné dokazuje i
> Strava podkladová mapa. Tím, že pěšinu smažete, nijak nemůžete
> zabránit tomu, aby ji někdo jiný opět nezmapoval. Naopak, les bez
> pěšin vypadá nezmapovaný a může přilákat dalšího uživatele, aby jej
> prošel a zmapoval. V OpenStreetMap neexistuje žádná značka "tento
> objekt nesmí být mapován". Takže pokud existuje, bude dříve, či
> později zmapován. To, zda je k objektu přístup či ne, se určuje pomocí
> dalších značek, například access=*. Upozorňuji ale, že nestačí, že si
> myslím, že by tam nikdo cizí nesměl chodit. To se určí buď nějakou
> oficiální dopravní značkou, nebo tím, že je daná místo oploceno. Ovšem
> dle platných zákonů není možné si v ČR jen tak oplotit les. Stejně tak
> není možné bránit vstupu do lesa a sběru lesních plodů a hub.//
> / /
> //Pokud bychom připustili, že si každý smaže to co se mu v mapě
> nelíbí, brzy bychom neměli mapu, ale pouze nějakou parodii na mapu.
> Uživatelé by nevěděli, co mohou očekávat na bílých místech, zda pouze
> není zmapováno, nebo zda je tam soukromý areál, který si nepřeje být
> na mapě, nebo někdo smazal kus cesty, aby mu kolem chaty nechodili
> lidi. A to je špatně.//
> / /
> //Pokud máte k problematice další dotazy, připojte se prosím do české
> emailové konference: 
> https://lists.openstreetmap.org/listinfo/talk-cz?language=cs//
> / /
> //Upozorňuji, že pokus o opětovné smazání těchto pěšin bude opět
> vyhodnocen jako vandalství a nahlášen Data Working Group, která může
> změny opět zrušit a dočasně, nebo trvale zablokovat Váš účet.//
> / /
> //S pozdravem,//
> //Marián Kyral/

Marián

… jaj, teď to čtu a hned v první větě jedno slovo dvakrát :-(
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

2017-08-30 Per discussione osm . sanspourriel

Le 30/08/2017 à 11:42, JB - jb...@mailoo.org a écrit :

Euh, juste pour me rassurer : Si vous faites une modification 
automatique, vous vous limitez à la France, hein ?
Déjà chez nous on n'est pas sûr d'être d'accord, mais si en plus on va 
mettre le bordel chez les voisins…

JB.
Je pense que ça va de soit mais autant effectivement le préciser ! Faire 
attention à bien respecter les frontières.


Par rapport au laïus de Philippe y a -t-il _dans OSM_ _en France_ un 
numéro français de plus de dix chiffres ?
Je corrige au passage l'affirmation "Mais vu de l'appelant il ne sait 
pas au départ en fait où est situé son correspondant: /en appelant un 
numéro fixe, il peut voir que la personne décroche avec son mobile/ qui 
n'est même pas forcément en France, mais l'appelant lui a appelé un 
numéro géographique français au prix d'un appel en France.". Non il ne 
voit pas forcément si le correspondant décroche d'un fixe ou d'un 
mobile, de même il peut y avoir une seule messagerie.  Mais ça une fois 
encore n'a rien à voir avec la question de départ sur la normalisation 
des numéros français en France.


Si jamais on a un numéro d'un tel PABX il va sans dire que les numéros à 
mettre dans OSM seront des numéros à 10 chiffres car ces numéros sont 
faits pour être joints. Qu'on puisse les joindre par un numéro plus 
long, OK mais il faut souvent en plus l'introduction d'un temps 
d'attendre (le temps de la bascule opérateur/PABX) pour que le PABX 
prenne le relai. Cette attente est prévue par la numérotation, pas par OSM.
De même un numéro de Tunisie affiché dans OSM pour appeler un numéro 
français vu comme un numéro tunisien... outre le fait que ce ne serait 
pas un numéro international (phone) mais un phone:TU, j'ai des doutes 
d'en voir un jour dans OSM.

La moulinette peut de toute façon avoir 3 sorties :
- rien à changer
- à changer automatiquement
- à regarder manuellement (tous les cas potentiellement pathologiques)

Mais si ça peut te faire plaisir, on dire "10 chiffres ou plus" 
internationalisable et le reste. Soit deux cas.
Je persiste à penser qu'on doit se pencher d'abord sur les numéros déjà 
en phone:FR ou phone:fr.
Après formater en un bloc pour les numéros courts, en 0X[ XX]+ pour les 
autres nationaux (si actuellement présentés en un paquet), en +33 X[ 
XX]+ pour les internationaux (là si actuellement présentés en un paquet 
ou +33 + paquet). Sinon transformer en gardant la trame de base (style 
0100 200 300 devenant +33 100 200 300).


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


Re: [OSM-talk-fr] quadruple no 46 à Rennes

2017-08-30 Per discussione Romain MEHUT
Fait https://www.openstreetmap.org/changeset/51593766

Romain

Le 28 août 2017 à 10:05, REBOUX Maël  a écrit :

> Bonjour Marc.
>
>
>
> Tout est normal : il y 4 adresses à cet endroit :
>
> 46 A
>
> 46 B
>
> 46 C
>
> 46 D
>
>
>
> https://data.rennesmetropole.fr/explore/dataset/adresses-
> du-referentiel-voies-et-adresses-de-rennes-metropole/
> map/?location=19,48.08982,-1.63288=233af6
>
>
>
> C’est « juste » la base OSM qui n’est pas à jour.
>
>
>
> Cdt,
>
>
>
> *Maël REBOUX*
> Service Information Géographique Rennes Métropole
> Chargé de mission "diffusion"
>
> 02 99 86 63 71
>
> Twitter : @mael_reboux_ig 
>
>
>
> A votre disposition :
>
> -   des *plans* *pdf de l'agglomération et de ses communes*
> téléchargeables
> 
> et imprimables
>
> -   un *plan interactif * de
> Rennes Métropole
>
> -   des *données publiques ouvertes
> *
>
>
>
> ___
> 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-cz] Ilegální pěšiny v lese?

2017-08-30 Per discussione Marián Kyral
Dne 28.8.2017 v 22:03 Pavel Machek napsal(a):
> AhoJ!
>
>> v karlovarském kraji se objevil nový uživatel, který maže "Ilegální" pěšiny
>> na pozemcích "Náboženská matice".
>>
>> https://www.openstreetmap.org/user/Radek%20Broz/history
>>
>> Co s ním?
> Revertovat, a reportovat na data working group.
>
> a) chodit po lese je legalni
>
> i kdyby nahodou nebylo
>
> b) mapujem realitu
>   Pavel

Pán mi na komentář k changesetu neodpověděl, revertoval jsem:
http://www.openstreetmap.org/changeset/51593471
http://www.openstreetmap.org/changeset/51593299

Ještě mu pošlu zprávu, kde se mu to pokusím vysvětlit.

Marián


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


Re: [OSM-talk-fr] le festival de tout les highway :-)

2017-08-30 Per discussione Romain MEHUT
Ce sujet avait été discuté sur la liste bretonne en mai cf.
https://lists.openstreetmap.org/pipermail/talk-fr-bzh/2017-May/002021.html
et les Rennais ne sont pas prompts à passer à living_street.

Le 22 août 2017 à 15:33, marc marc  a écrit :

> Le 21. 08. 17 à 21:35, djakk djakk a écrit :
> > une route primaire en même temps living_street c'est simple, tu
> > mets ce panneau carré bleu avec des piétons et une "limitation à 20
> > km/h" incrusté sur un des axes les plus importants d'une ville
> Si rien d'autre n'a été fait, c'est 0/20 pour le responsable de
> l'aménagement mais niveau osm c'est à mon avis limpide :
>
> La route/zone couverte par le panneau living_street est uniquement
> living_street car la priorité est le piéton, il peux circuler sur cet
> espace comme bon lui semble, jouer au ballon, faire son lacet où bon lui
> semble, même sans aménagement agréable, cet espace a perdu sa vocation
> prioritaire au transit.
>
> Le bout de route avant et après cette zone à mes yeux devrait lui aussi
> être rétrogradé de primaire à au maximum tertiaire voir résidentiel au
> moins jusqu'au gros carrefour précédent et suivant.
>
> Après que le routage ou les habitués décident de passer avec un 40T
> parce qu'il gagne 2 min ou simplement parce que "c'était comme cela
> avant", à mon avis ce n'est pas cela qui change la situation.
> Si le trafic de transit utilise réellement toujours ce trajet, je pense
> qu'il y aussi un 0/20 pour la signalisation au carrefour précédent et
> pour la non-maj des gps éventuellement utilisé par les non-locaux.
>
> Ce n'est bien sur que mon avis et je sais que les gens détestent les
> changements administratifs si cela ne leur conviennent pas.
> Mais l'unique autre solution c'est de tager dans osm selon son envie
> subjective de à quoi devrait servir la route en ignorant les panneaux,
> Cela me semble conduire vers des données moins utilisable puisque le
> routage va envoyer un 40T en transit sur une route inadaptée.
> Si la communauté locale ne veux pas de la maj, ce n'est pas moi qui irai
> la faire, je suis pour les compromis autant que possible :-)
> Je pense cependant que cela mérite réflexion "locale" pour faire la part
> entre nostalgie et situation réelle.
> Cela mérite aussi un message à l'administration s'il y a des problèmes
> de qualité (aménagement, signalisation)
> ___
> 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] fontanella a volte chiusa

2017-08-30 Per discussione Any File
2017-08-30 10:22 GMT+02:00 demon.box :
> ciao, come taggo una fontanella come questa:
>
> 
>
> che a volte (come ieri sera) trovo chiusa?
>

Esiste una Key intermittent
https://wiki.openstreetmap.org/wiki/Key:intermittent

ma è stata pensata per i fiumi o simili.

La trovi chiusa: intendi che non esce acqua o che non puoi arrivare
nel punto in cui c'è la fontanella?

AnyFile

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


Re: [Talk-cz] Znaceni pruchodnosti was Re: WeeklyOSM CZ 367

2017-08-30 Per discussione Jan Macura
2017-08-30 19:00 GMT+02:00 Jan Martinec :

> Ty orienťácký mapy jsem uvedl jako snadno dohledatelný příklad - pokud
> vím, mají zcela uzavřenou licenci, takže z nich nemůžeme čerpat o nic víc
> než z těch tajných vojenských;)
>

Apriori ano, ale vydavatel může práva uvolnit. Není to dirigováno plošně.

(...) v papíru si dělají aktualizace cca co rok-dva. Když si srovnám mapy
> "Hrádek" za posledních pár vydání, (...)
>

Hehe, tak to fakt platí o těch pár prasolesích kolem Práglu, Tambudic nebo
Krna :-)

Ten ÚHÚL to má více nebo méně podrobně? A mají nějakou strojovou čitelnost,
> nebo bychom to museli obkreslit (za předpokladu licenční kompatibility)?
>

Pokud jsi měl někdy v ruce orienťáckou mapu, tak znáš odpověď.
Našel jsem akorát WMSku. Víc viz hvězdičku v předchozím mailu a
http://www.uhul.cz/mapy-a-data/katalog-mapovych-informaci . Na webu mají k
licenčním podmínkám celou vyhlášku MZe, kterou se mi [teď] číst nechce:
http://www.uhul.cz/mapy-a-data/poskytovani-dat/pravidla-mze-cr

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


Re: [OSM-talk-fr] projet du mois : postes de secours

2017-08-30 Per discussione Romain MEHUT
Bonsoir,

Le 12 août 2017 à 14:51,  a écrit :

>
> Enfin ces postes de secours sont référencés dans la base de l'agglo du nom
> de la plage ref_plage=Le Loc'h.
> Je vois que le poste de secours existant était noté "Poste de secours du
> Loc'h".
> Logiquement comme c'est un poste de secours et qu'il est proche du
> lieu-dit Le Loc'h et que la plage est dite du Loc'h, met-on son nom ou pas ?
>

On met ce que l'on voit sur le terrain même. On a déjà eu cette discussion
maintes fois...


> Autre détails : je vois de simples places de parking réservées aux
> camping-cars qualifiés de tourism=caravan_site. Est-ce que ça vous semble
> normal ?
>

Je laisserai dans la mesure où c'est effectivement bien identifié pour les
camping-cars. A contrario, j'ai déjà supprimé ce tag pour des endroits où
il n'y a aucune marque de réservation pour les camping-cars.

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


Re: [Talk-cz] Názvy vodních nádrží a water=reservoir

2017-08-30 Per discussione Marián Kyral
Dne 30.8.2017 v 20:29 Marián Kyral napsal(a):
> Dne 30.8.2017 v 19:22 Jan Macura napsal(a):
>> Ahoj,
>>
>> 2017-08-30 11:48 GMT+02:00 Marián Kyral > >:
>>
>> A dá se to nějak porovnat s katastrem?
>>
>> Třeba přehrada Olešná u FM, se dle katastru oficiálně jmenuje
>> "VODNÍ NÁDRŽ OLEŠNÁ"
>>
>>
>> jestli někam koukat pro jméno, tak do Geonames
>> .
>> I když v současnosti už by to mělo být převážně shodný s KN mapou.
>>
>>
>
> Hmm, tak v tomto případě je v GeoNames: v. n. Olešná, tedy to co
> je/bylo v OSM - právě se to chystám změnit :-D
>

… a nedaleké Žermanice mají v katastru "Žermanická přehrada" a v
GeoNames: "v. n. Žermanice" - co je tedy oficiální název?

Marián


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


Re: [Talk-cz] Názvy vodních nádrží a water=reservoir

2017-08-30 Per discussione Marián Kyral
Dne 30.8.2017 v 19:22 Jan Macura napsal(a):
> Ahoj,
>
> 2017-08-30 11:48 GMT+02:00 Marián Kyral  >:
>
> A dá se to nějak porovnat s katastrem?
>
> Třeba přehrada Olešná u FM, se dle katastru oficiálně jmenuje
> "VODNÍ NÁDRŽ OLEŠNÁ"
>
>
> jestli někam koukat pro jméno, tak do Geonames
> .
> I když v současnosti už by to mělo být převážně shodný s KN mapou.
>
>

Hmm, tak v tomto případě je v GeoNames: v. n. Olešná, tedy to co je/bylo
v OSM - právě se to chystám změnit :-D

Marián

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


Re: [Talk-cz] Chatová osada

2017-08-30 Per discussione marek

https://wiki.openstreetmap.org/wiki/Cs:Tag:tourism%3Dchalet
 
Marek Polák
 
__

Od: Marián Kyral 
Komu: talk-cz@openstreetmap.org
Datum: 30.08.2017 20:20
Předmět: Re: [Talk-cz] Chatová osada


Dne 30.8.2017 v 20:15 marek napsal(a):Už jsem našel asi správnou volbu.
tourism=chalet+Jcamp

takhle přesně se to zapisuje?

Marián




--

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


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


Re: [Talk-cz] Chatová osada

2017-08-30 Per discussione Marián Kyral
Dne 30.8.2017 v 20:15 marek napsal(a):
>
> Už jsem našel asi správnou volbu.
>
> tourism=chalet+Jcamp
>

takhle přesně se to zapisuje?

Marián


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


Re: [Talk-cz] Chatová osada

2017-08-30 Per discussione marek

Už jsem našel asi správnou volbu.
tourism=chalet+Jcamp

Marek Polák
 
__

Od: Jan Macura 
Komu: OpenStreetMap Czech Republic 
Datum: 30.08.2017 19:13
Předmět: Re: [Talk-cz] Chatová osada


Ahoj,

zajímavý dotaz. Viděl bych to buď na tourism=camp_sitenebo tourism=hostel + 
landuse=recreation_ground, jak se píše tady dol 
e.

H.
2017-08-29 17:35 GMT+02:00 Marek Polák >:
Do které kategorie mám zařadit ubytování v chatkách? http://www.jcamp.cz 

Marek Polák



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


--

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


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


Re: [Talk-cz] Názvy vodních nádrží a water=reservoir

2017-08-30 Per discussione Michal Poupa
Ten Geonames se platí?


30. 8. 2017 v 19:22, Jan Macura :

> Ahoj,
> 
> 2017-08-30 11:48 GMT+02:00 Marián Kyral :
>> A dá se to nějak porovnat s katastrem? 
>> 
>> Třeba přehrada Olešná u FM, se dle katastru oficiálně jmenuje "VODNÍ NÁDRŽ 
>> OLEŠNÁ"
> 
> jestli někam koukat pro jméno, tak do Geonames. I když v současnosti už by to 
> mělo být převážně shodný s KN mapou.
> 
> H.
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [Talk-br] Mapeamento hidrológico

2017-08-30 Per discussione Guilherme Peev
Aliás a ANA fornece os shapefiles hidrográficos dela, não?


Em qua, 30 de ago de 2017 às 14:02, Flavio Bello Fialho <
bello.fla...@gmail.com> escreveu:

> A proposta "major/big/small" não me parece inútil. Pelo contrário, parece
> ser bastente útil para definir quais cursos representar em diferentes
> escalas do mapa, além de ser simples de implementar. A Otto Codificação é
> muito interessante e permite identificar bacias individuais. Nada impede
> que se usem as duas, pois não são incompatíveis. Na minha opinião, o mais
> crítico é traçar a hidrografia no mapa. Tenho algumas dúvidas:
>
> 1. Qual é o critério para diferenciar "waterway=stream" de
> "waterway=river"?
>
> 2. Sempre que for traçado um "waterway=river" deve-se traçar também uma
> área com tag "waterway=riverbank"?
>
> 3. Como definir os limites de "natural=wetland"?
>
> Em 30 de agosto de 2017 10:57, Cassio Eskelsen 
> escreveu:
>
>> A proposta de definir como "major/big/small" considero inútil e que não
>> agrega nada.
>>
>> A outra proposta é interessante. O número de Strahler é comumente
>> utilizado em GIS, mas no Brasil não é tão usado já que nos acostumados com
>> a Otto Codificação.
>> A Otto Codificação é mais complexa, não sei se eles aceitariam, até pq
>> não se usa tanto la fora.
>>
>> Cássio Rogério Eskelsen
>> 3Geo
>>
>> 2017-08-30 8:20 GMT-03:00 Nelson A. de Oliveira :
>>
>>> Dá uma olhada nessas propostas (que são recentes e estão sendo
>>> discutidas na tagging):
>>>
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Waterways_classification
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Rivers_Classification
>>>
>>> ___
>>> Talk-br mailing list
>>> Talk-br@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>
>>
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>
>
> --
> Flávio Bello Fialho
> bello.fla...@gmail.com
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
-- 
Guilherme Peev dos Santos.
Tel.: +55 (11) 998-613-318 (TIM)

Preserva as informações de seus conhecidos, use cópia oculta (Cco ou Bcc)
para seus endereços de e-mail
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br


Re: [Talk-cz] Názvy vodních nádrží a water=reservoir

2017-08-30 Per discussione Jan Macura
Ahoj,

2017-08-30 11:48 GMT+02:00 Marián Kyral :

> A dá se to nějak porovnat s katastrem?
>
> Třeba přehrada Olešná u FM, se dle katastru oficiálně jmenuje "VODNÍ NÁDRŽ
> OLEŠNÁ"
>

jestli někam koukat pro jméno, tak do Geonames
.
I když v současnosti už by to mělo být převážně shodný s KN mapou.

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


Re: [Talk-it] fontanella a volte chiusa

2017-08-30 Per discussione girarsi_liste
Il 30/08/2017 10:22, demon.box ha scritto:
> ciao, come taggo una fontanella come questa:
> 
>  
> 
> che a volte (come ieri sera) trovo chiusa?
> 
> la fontanella si trova in una valletta, in mezzo al bosco, fuori dal centro
> abitato ma accanto ad un piccolo rifugio gestito ed aperto solo nei fine
> settimana.
> 
> in questo caso credo che l'acqua arrivi da una sorgente captata più a monte
> che forse con la siccità di questa estate si è prosciugata.
> 
> in altri casi invece mi capita la stessa cosa magari con la classica vasca
> di abbeveraggio per gli animali (amenity=watering_place) vicino ad una
> malga, dove però sono certo che è l'uomo che decide di chiudere l'acqua
> (magari tramite un rubinetto nascosto e non liberamente accessibile).
> 
> concludendo, in questi casi come faccio ad indicare che l'acqua a volte non
> c'è?
> grazie
> --enrico

Capisco poco l'inglese, e da motore di traduzione, con rubinetto, ed
allacciato, forse alla rete idrica, dovrebbe essere:

http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_tap

Se si può bere:

drinking_water=yes


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



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


Re: [Talk-cz] Chatová osada

2017-08-30 Per discussione Jan Macura
Ahoj,

zajímavý dotaz. Viděl bych to buď na tourism=camp_site
nebo tourism=hostel + landuse=recreation_ground, jak se píše tady dol
e.

H.

2017-08-29 17:35 GMT+02:00 Marek Polák :

> Do které kategorie mám zařadit ubytování v chatkách? http://www.jcamp.cz
> Marek Polák
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [Talk-br] Mapeamento hidrológico

2017-08-30 Per discussione Flavio Bello Fialho
A proposta "major/big/small" não me parece inútil. Pelo contrário, parece
ser bastente útil para definir quais cursos representar em diferentes
escalas do mapa, além de ser simples de implementar. A Otto Codificação é
muito interessante e permite identificar bacias individuais. Nada impede
que se usem as duas, pois não são incompatíveis. Na minha opinião, o mais
crítico é traçar a hidrografia no mapa. Tenho algumas dúvidas:

1. Qual é o critério para diferenciar "waterway=stream" de "waterway=river"?

2. Sempre que for traçado um "waterway=river" deve-se traçar também uma
área com tag "waterway=riverbank"?

3. Como definir os limites de "natural=wetland"?

Em 30 de agosto de 2017 10:57, Cassio Eskelsen 
escreveu:

> A proposta de definir como "major/big/small" considero inútil e que não
> agrega nada.
>
> A outra proposta é interessante. O número de Strahler é comumente
> utilizado em GIS, mas no Brasil não é tão usado já que nos acostumados com
> a Otto Codificação.
> A Otto Codificação é mais complexa, não sei se eles aceitariam, até pq não
> se usa tanto la fora.
>
> Cássio Rogério Eskelsen
> 3Geo
>
> 2017-08-30 8:20 GMT-03:00 Nelson A. de Oliveira :
>
>> Dá uma olhada nessas propostas (que são recentes e estão sendo
>> discutidas na tagging):
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Waterw
>> ays_classification
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Rivers
>> _Classification
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>


-- 
Flávio Bello Fialho
bello.fla...@gmail.com
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br


Re: [Talk-cz] Znaceni pruchodnosti was Re: WeeklyOSM CZ 367

2017-08-30 Per discussione Jan Martinec
Ty orienťácký mapy jsem uvedl jako snadno dohledatelný příklad - pokud vím,
mají zcela uzavřenou licenci, takže z nich nemůžeme čerpat o nic víc než z
těch tajných vojenských;)

Co se zastaralosti týče, vědí o tom - ale ty mapy používají fakt fest, tj.
jejich mapaři v tom lese prakticky bydlí - takže i v papíru si dělají
aktualizace cca co rok-dva. Když si srovnám mapy "Hrádek" za posledních pár
vydání, tak největší změny jsou právě v průchodnosti, i když beru "les
povyrostl" za ne-změnu: ten stav "a tady něco bylo, a už to tady není, je
to prořezaný nebo naopak zaškolkovaný" je hodně častý. Tohle se dá udržet
aktuální pro těch 30 předem vybraných lokací okolo Prahy,  ale ne pro české
lesy komplet - leda by byl plně automatický feed odněkud.

Ten ÚHÚL to má více nebo méně podrobně? A mají nějakou strojovou čitelnost,
nebo bychom to museli obkreslit (za předpokladu licenční kompatibility)?

Zdar,
HPM
Dne 30. 8. 2017 18:44 napsal uživatel "Jan Macura" :

Ahoj,

2017-08-29 14:04 GMT+02:00 Jan Martinec :

> To "dost práce" je velký understatement: hleďme, na kolik desítek ploch se
> rozpadne jeden středně velký les, pokud bychom ho chtěli alespoň v
> orienťáckém rozdělení "světlina/průběžný/průchodný/neprůchodný":
> http://www.openstreetmap.org/relation/4664360
> vs
> http://mapy.orientacnisporty.cz/mapa/hradek-2012
> - a to ještě je mapa, kde jsou ty typy relativně souvislé, co teprve Brdy.
>
> Navíc takhle podrobně mají OB zmapovaných několik desítek lokací, rozhodně
> ne celou republiku - protože nemají sto tisíc mapařů, kteří by to drželi
> aktuální; i pokud by to šlo tahat odněkud plně automaticky, bude to projekt
> minimálně srovnatelně náročný s importem budov.
>

z OB map to fakt v současném stavu automaticky tahat nejde. Navíc
promapováno je tak 5–10 % území ČR, z toho značná část už bude zastaralá.

Pokud bychom průchodnost chtěli odvozovat ze stáří lesa, tak data má ÚHÚL*,
jak už tu bylo zmiňováno, ovšem v úplně jiné podrobnosti.

A ještě jen tak pro zajímavost: Vojáci mají
 Mapu
průchodnosti terénu v měřítku 1:100 000, která je CLASSIFIED.

H.

* Nepodařilo se mi všechny dohledat, protože *"Mapové aplikace ÚHÚL jsou
primárně určeny pro internetový prohlížeč Internet Explorer. V případě
alternativních prohlížečů nelze zaručit plnou funkcionalitu, případně
správnou funkčnost. A to zejména s ohledem na širokou variabilitu
používaných verzí těchto prohlížečů a možnosti instalace rozličných
doplňků, které mohou způsobit nestandardní chování aplikací."*

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


Re: [Talk-cz] Znaceni pruchodnosti was Re: WeeklyOSM CZ 367

2017-08-30 Per discussione Jan Macura
Ahoj,

2017-08-29 14:04 GMT+02:00 Jan Martinec :

> To "dost práce" je velký understatement: hleďme, na kolik desítek ploch se
> rozpadne jeden středně velký les, pokud bychom ho chtěli alespoň v
> orienťáckém rozdělení "světlina/průběžný/průchodný/neprůchodný":
> http://www.openstreetmap.org/relation/4664360
> vs
> http://mapy.orientacnisporty.cz/mapa/hradek-2012
> - a to ještě je mapa, kde jsou ty typy relativně souvislé, co teprve Brdy.
>
> Navíc takhle podrobně mají OB zmapovaných několik desítek lokací, rozhodně
> ne celou republiku - protože nemají sto tisíc mapařů, kteří by to drželi
> aktuální; i pokud by to šlo tahat odněkud plně automaticky, bude to projekt
> minimálně srovnatelně náročný s importem budov.
>

z OB map to fakt v současném stavu automaticky tahat nejde. Navíc
promapováno je tak 5–10 % území ČR, z toho značná část už bude zastaralá.

Pokud bychom průchodnost chtěli odvozovat ze stáří lesa, tak data má ÚHÚL*,
jak už tu bylo zmiňováno, ovšem v úplně jiné podrobnosti.

A ještě jen tak pro zajímavost: Vojáci mají
 Mapu
průchodnosti terénu v měřítku 1:100 000, která je CLASSIFIED.

H.

* Nepodařilo se mi všechny dohledat, protože *"Mapové aplikace ÚHÚL jsou
primárně určeny pro internetový prohlížeč Internet Explorer. V případě
alternativních prohlížečů nelze zaručit plnou funkcionalitu, případně
správnou funkčnost. A to zejména s ohledem na širokou variabilitu
používaných verzí těchto prohlížečů a možnosti instalace rozličných
doplňků, které mohou způsobit nestandardní chování aplikací."*
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [Talk-us] South Bay community meetup, Sept. 23 in San Jose

2017-08-30 Per discussione Martijn van Exel
That's great. I forwarded to some of my SV contacts who I know are interested 
in OSM. Good luck!

Sent from my iPad

> On Aug 30, 2017, at 10:17, Minh Nguyen  wrote:
> 
> We're (re)starting an OpenStreetMap community in the South Bay, starting with 
> a meetup in San Jose next month. Code for San Jose is sponsoring the event as 
> part of the National Day of Civic Hacking.
> 
> Please RSVP and invite anyone you know who might be interested in OSM. Here 
> are the details:
> 
> Saturday, September 23, 2017
> 10:00 AM to 5:00 PM
> 
> The Tech Museum Design Challenge Learning Institute
> 145 West San Carlos Street, San Jose, CA
> https://www.openstreetmap.org/way/499736149
> 
> More information:
> https://www.meetup.com/Code-for-San-Jose/events/242474711/
> 
> -- 
> m...@nguyen.cincinnati.oh.us
> 
> 
> ___
> 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


[Talk-us] talk-us-sfbay

2017-08-30 Per discussione Minh Nguyen
There's a new talk-us-sfbay mailing list for discussing issues specific 
to the San Francisco Bay Area and Northern California in general:


https://lists.openstreetmap.org/listinfo/talk-us-sfbay/

You're welcome to join regardless of where you live or map, but be 
forewarned that you may have to put up with hyperlocal discussions at 
times. ;-)


--
m...@nguyen.cincinnati.oh.us


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


[Talk-us] South Bay community meetup, Sept. 23 in San Jose

2017-08-30 Per discussione Minh Nguyen
We're (re)starting an OpenStreetMap community in the South Bay, starting 
with a meetup in San Jose next month. Code for San Jose is sponsoring 
the event as part of the National Day of Civic Hacking.


Please RSVP and invite anyone you know who might be interested in OSM. 
Here are the details:


Saturday, September 23, 2017
10:00 AM to 5:00 PM

The Tech Museum Design Challenge Learning Institute
145 West San Carlos Street, San Jose, CA
https://www.openstreetmap.org/way/499736149

More information:
https://www.meetup.com/Code-for-San-Jose/events/242474711/

--
m...@nguyen.cincinnati.oh.us


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


Re: [OSM-talk-fr] Distinction power line/minor_line en France

2017-08-30 Per discussione Philippe Verdy
Le 30 août 2017 à 15:33, Christian Quest  a écrit :

> Se baser sur la tension ne me semble pas une bonne idée car sur le terrain
> il n'est pas du tout évident de savoir le voltage sauf si on est un fondu
> des réseaux électriques.
>
> Par contre, les pylônes/poteaux sont un élément visuel beaucoup plus
> facile à évaluer (en gros 1 pied = pole, plusieurs pieds = tower, simpliste
> mais facile à reconnaitre pour un profane)
>

Je suis d'accord aussi : ce qu'on voit et sert au repérage est plus
important que le reste. Ensuite le détail de la séparation entre réseaux de
distribution et réseau de transport a des subtilités qui m'échappe beaucoup
mais ne dépend même pas des éléments purement techniques invisibles comme
la tension réellement appliquée

(et le type de modulation utilisé : continu ou alternatif, le continu ayant
maintenant de plus en plus la "cote" en très haute tension et pour le
transport international ou sous-marin à des puissances très élevées et avec
beaucoup moins de perte et moins d'effet néfaste en terme de pollution du
spectre radio car on sait plus facilement "écranter" un champ électrique
quasi-statique qu'un champ électrique alternatif qui, avec les variations
de charge, produit un champ magnétique et un effet inductif
particulièrement néfaste avec des "pics" de courants très importants
détruisant facilement les équipements et émettant des ondes à forte
puissance sur un spectre plus large. L'intérêt du courant alternatif était
sa facilité de transformer les tensions pour aller vers la très haute
tension, afin de réduire les courants et les pertes résistives, mais cela
n'a pas réglé les pertes inductives et on sait combien les émissions
électromagnétiques sont gênantes. Pour le courant continu, on ne savait pas
à l'époque faire les transformations à haute tension, mais maintenant on a
des composants efficaces même pour les fortes puissances).

Les subtilités entre réseau de transport et réseau de distribution sont des
différences surtout légales et de compétence sur des entités territoriales
permettant l'exercice de la concurrence à la distribution. C'est largement
indépendant des caractéristiques techniques des circuits d'acheminement (la
tension n'est pas pertinente, ni la modulation). En revanche la puissance
acheminée par un circuit l'est beaucoup plus mais c'est surtout le nombre
de consommateurs finals desservis et le type de personnalité légale du
client/producteur (particulier, entreprise, service public).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-es] Debemos comprobar el nombre de 2800 vías.

2017-08-30 Per discussione Jo
A mi me parece que lo más facil es esperar que pasa la redacción y pues
agir y corregir. Buscando al mismo tiempo otros nombres que faltan o que
son diferentes de las fuentes admisibles.

Polyglot

2017-08-30 17:46 GMT+02:00 alan_gr :

> Frederik ha respondido a mi pregunta [1]. Me atrevo a traducir lo
> principal.
>
> Confirma que el plan actual es resetear la etiqueta "name=" (y también
> "name:es" etc. si chdr ha cambiado estos) a lo que era antes de la edición
> de chdr.
>
> Habrá dos excepciónes:
> 1. Si el nombre ha sido cambiado por otro usuario después de chdr, no se
> borrará. Cuidado que este se refiere solo al nombre, no a otras etiquetas
> cómo "source=". Si cambiamos "source=" sin cambiar el nombre, tendremos que
> editar la calle de nuevo después de la redacción. Eso sí, si por casualidad
> encontramos en la lista nombres que no son correctos, podemos cambiarlos
> ahora mismo y no se borrará el nuevo nombre.
>
> 2. Si podemos identificar casos en lo cual chdr no importó ningún dato
> nuevo
> sino corregió un data existente, podemos avisar a Frederik para que saque
> estos de la lista. Por ejemplo si el nombre había sido puesto antés por
> otro
> usuario y chdr se haya limitado a poner "Avenida" dónde antes había "Av".
> En
> estos casos el nombre no está "contaminado" y no será necesario borrarlo.
> En Estados Unidos parece que dentro de los cambios de chdr hay bastante
> casos así, por ejemplo cambios de "N" a "North". No sé si vamos a encontrar
> lo mismo en España.
>
> Frederik dice que espera hacer la redacción en septiembre, pero no antes
> del
> día 15.
>
>
> [1]
> http://gis.19327.n8.nabble.com/Redacting-75-000-street-
> names-contributed-by-user-chdr-tp5901701p5901757.html
>
>
>
>
>
> --
> View this message in context: http://gis.19327.n8.nabble.
> com/Debemos-comprobar-el-nombre-de-2800-vias-tp5901562p5901774.html
> Sent from the Spain mailing list archive at Nabble.com.
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es


Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr (Spain)

2017-08-30 Per discussione alan_gr
Thanks Frederik - I will pass that on to talk-es. 

My next question was going to be about name:xx, but you beat me to it!



--
View this message in context: 
http://gis.19327.n8.nabble.com/Redacting-75-000-street-names-contributed-by-user-chdr-tp5901701p5901775.html
Sent from the General Discussion mailing list archive at Nabble.com.

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


Re: [Talk-es] Debemos comprobar el nombre de 2800 vías.

2017-08-30 Per discussione alan_gr
Frederik ha respondido a mi pregunta [1]. Me atrevo a traducir lo principal.

Confirma que el plan actual es resetear la etiqueta "name=" (y también
"name:es" etc. si chdr ha cambiado estos) a lo que era antes de la edición
de chdr.

Habrá dos excepciónes:
1. Si el nombre ha sido cambiado por otro usuario después de chdr, no se
borrará. Cuidado que este se refiere solo al nombre, no a otras etiquetas
cómo "source=". Si cambiamos "source=" sin cambiar el nombre, tendremos que
editar la calle de nuevo después de la redacción. Eso sí, si por casualidad
encontramos en la lista nombres que no son correctos, podemos cambiarlos
ahora mismo y no se borrará el nuevo nombre. 

2. Si podemos identificar casos en lo cual chdr no importó ningún dato nuevo
sino corregió un data existente, podemos avisar a Frederik para que saque
estos de la lista. Por ejemplo si el nombre había sido puesto antés por otro
usuario y chdr se haya limitado a poner "Avenida" dónde antes había "Av". En
estos casos el nombre no está "contaminado" y no será necesario borrarlo. 
En Estados Unidos parece que dentro de los cambios de chdr hay bastante
casos así, por ejemplo cambios de "N" a "North". No sé si vamos a encontrar
lo mismo en España. 

Frederik dice que espera hacer la redacción en septiembre, pero no antes del
día 15. 


[1]
http://gis.19327.n8.nabble.com/Redacting-75-000-street-names-contributed-by-user-chdr-tp5901701p5901757.html





--
View this message in context: 
http://gis.19327.n8.nabble.com/Debemos-comprobar-el-nombre-de-2800-vias-tp5901562p5901774.html
Sent from the Spain mailing list archive at Nabble.com.

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


Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

2017-08-30 Per discussione Philippe Verdy
Le 30 août 2017 à 17:04, Christian Quest  a écrit :

> Il me semble donc que seuls les numéros en "services téléphoniques" sont
> utilisables à l'international (donc avec +33), soit:
> - 01..07
>  - 09

et 0870 que tu oublies (ce sont des numéros VoIP des box internets, dans un
tranche qui a été utilisée avant l'allocation d'ajouter le 09, mais ces
numéros à 10 chiffres 0870 sont toujours valides)
Il n'est pas inutile donc de consulter les pages de l'ARCEP consacrées au
plan de numérotation !

De plus des numéros 01... à 05... à plus de 10 chiffres existent aussi en
France (dans certains blocs alloués non pas à un opérateur classique mais à
une entreprise: le bloc entier comprend 6 à 8 chiffres initiaux (dont le
préfixe 0 initial) qui sont tous routés vers un PABX quelque soient les
chiffres qui suivent, ensuite l'entreprise a configuré des numéros
"publics" en allouant les 4 à 2 chiffres qui restent en sous blocs,
certains sous blocs utilisant des chiffres supplémentaires dit de
"sélection directe à l'arrivée".

Si on appelle un numéro à 10 chiffres dans le bloc alloué à l'entreprise et
qu'il manque des chiffres de sélection directe à l'arrivée, le PABX
redirige vers un numéro simple à 10 chiffres, celui d'un standard ou
accueil téléphonique, ou vers un robot qui proposera des options ou mettra
en relation avec une personne d'accueil. On peut éviter ce robot en
composant directement le numéro "long" avec tous les chiffres, et on peut
même appeler dans certains cas avec uniquement les 6 à 8 premiers chiffres
(dont le préfixe 0) des numéros plus courts configurés par le PABX qui gère
son propre plan de numérotation interne. Ces numéros longs permettent par
exemple d'appeler avec un numéro fixe des destinataires précis d'une
"flotte" d'entreprise, où qu'ils soient et même s'ils ne sont pas au siège
de l'entreprise mais contactables par leur mobile (le PABX prendra à sa
charge la mise en relation éventuellement via un autre opérateur, ou tout
autre moyen que le réseau téléphonique publique). Mais vu de l'appelant il
ne sait pas au départ en fait où est situé son correspondant: en appelant
un numéro fixe, il peut voir que la personne décroche avec son mobile qui
n'est même pas forcément en France, mais l'appelant lui a appelé un numéro
géographique français au prix d'un appel en France.

C'est beaucoup moins utilisé en France  qu'en Allemagne ou au Royaume-Uni.
En France, le plan général à "10 chiffres" (nécessaires et suffisants)
n'est imposé que pour les abonnés particuliers et les numéros dits "à
valeur ajoutés" ou numéros "verts", ainsi que les centres d'appel, mais les
opérateurs ont beaucoup de libertés pour adapter tout en utilisant le plan
de numérotation standard). Mais en Allemagne le cas typique est d'avoir des
petites tranches de numéros alloués à l'entreprise qui ajoute ensuite de 1
à 3 chiffres pour ses besoins propres (c'est très fréquent et cela dépend
fortement des Länder) et on n'a pas du tout de format unique et pas non
plus de présentation en groupes de 2 chiffres uniquement (on y préfère les
groupes de 3 ou 4 chiffres et les entreprises qui ont des PABX configurés
avec SDA préfèrent grouper les derniers chiffres de la SDA et les séparer
des premiers chiffres du plan public et du groupe qui leur est alloué).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk] JOSM Custom Presets - Combo to set multiple tags

2017-08-30 Per discussione Mike Thompson
Hi François,

> I don't think so since the combo box has a unique key name set in its
definition
That is what I thought, thanks for the confirmation.

> What you can do though is to set the first key with a fixed value
(religion=chrisitian) and let user pick for denomination
The use case I was thinking of was something like the following (this is
somewhat contrived and simplified for the purposes of illustration):
display_value="Roman Catholic, Muslim"
If the user selects "Roman Catholic", religion=christian,
denomination=roman_catholic; if the user selects "Muslim": religion=muslim,
denomination=(tag removed)

Mike


On Tue, Aug 29, 2017 at 10:49 AM, François Lacombe <
fl.infosrese...@gmail.com> wrote:

> Hi Mike
>
> I don't think so since the combo box has a unique key name set in its
> definition
>
> What you can do though is to set the first key with a fixed value
> (religion=chrisitian) and let user pick for denomination
>
> Let us know how is it going
>
> François
>
>
> Le 29 août 2017 5:44 PM, "Mike Thompson"  a écrit :
>
> I am learning how to create custom presets for JOSM.
>
> Is there a way to have a "combo" list set multiple tags? For example (just
> to illustrate the question), to make it so that if the user picks "Roman
> Catholic", religion=christian and denomination=roman_catholic are both set?
>
> Thanks,
> Mike
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-br] Mapeamento hidrológico

2017-08-30 Per discussione santamariense
> Acho que isso não é necessário, da mesma forma que não definimos
> explicitamente que Rua Tal está na cidade Tal.

Então, pretendem subir ao OSM a delimitação de bacias hidrográficas?

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


Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

2017-08-30 Per discussione Philippe Verdy
Le 30 août 2017 à 11:36, Francois Gouget  a écrit :

> On Tue, 29 Aug 2017, marc marc wrote:
>
> > Le 29. 08. 17 à 04:31, Francois Gouget a écrit :
> > > je ne connais pas trop le format des numéros de téĺéphone
> > > dans les autres pays.
> >
> > le format est international :)
>
> Je voulais dire que je ne sais pas s'il faut enlever le 0 pour les
> autres pays. Apparemment il ne faut pas pour l'Italie. (+39)
>

Il ne faut pas le faire non plus pour le Royaume-Uni (+44).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

2017-08-30 Per discussione Christian Quest

Le 30/08/2017 à 15:42, marc marc a écrit :

Le 30. 08. 17 à 11:42, JB a écrit :
  > Si vous faites une modification automatique,
  > vous vous limitez à la France, hein ?
Si/lorsque le programme existe, ce serrait bête
de ne pas l'utiliser ailleurs, non ?
pas une "hop corrigeons le monde", mais au cas
par cas ou un message sur la liste mondiale ou wiki
pour recenser les exceptions à la règle


Mettons nous déjà d'accord pour le faire (proprement) sur la France ;)


J'ai testé de chez moi avec +33 3631. Ça marche pas.

Merci pour le test.
Du coup je propose de voir ces là séparément (clef  phone:FR)
Sauf si quelqu'un a le temps/envie de faire cela en même temps.


D'autres numéros spéciaux ne fonctionnent pas à l'international comme 
les 08 xx


L'ARCEP a sûrement une liste car celle elle qui distribue les préfixes 
téléphoniques.


Voici le plan de numérotation: https://www.arcep.fr/?id=8146#c7916

Il me semble donc que seuls les numéros en "services téléphoniques" sont 
utilisables à l'international (donc avec +33), soit:

- 01..07
- 09

--
Christian Quest - OpenStreetMap France


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


[talk-ph] Cagayan de Oro roads and streets need reclassification

2017-08-30 Per discussione Jherome Miguel
The mapping of roads and streets in Cagayan de Oro are a mess again this
time. I have fixed the classification of the majority, but it was reverted
back to the messed-up classifications. As I saw, some roads I reclassified
(highway =trunk or primary->lower classification) are reverted back to the
wrong classifications. There are too many roads classified as "trunk" and
"primary", even when those are not travelled very much.

Mukhang ang gulo na naman uli nung pagkakamapa ng karamihan ng mga
kalsada't kalye sa Cagayan de Oro. Una, inayos ko na yung klasipikasyon ng
karamihan, ngunit ibinalik na naman sa mas gulong klasipikasyon ng mga
kalsada. Pagkakita ko, ilang kalsadang pinalitan ko ng klasipikasyon
(highway="trunk" o "primary"->mas mababang klasipikasyon) ay ibinalik sa
maling klasipikasyon. Ang sobrang dami uli ng mga lansangang may
klasipikasyon ng "trunk" at "primary", kahit hindi naman talaga silang
gaanong dinadaanan ng napakaraming mga sasakyan.

Daw ang kasamok mao nga ang pag-usab sa pagmapa sa kadaghanan sa kadalanan
sa Cagayan de Oro. Una, gisusi ko ang kadaghanan sa mga klasipikasyon, apan
mibalik sa mas makahasol nga klasipikasyon sa mga kadalanan. Sumala sa
akong nakita, ang pipila sa mga dalan nga akong gipulihan sa klasipikasyon
(highway = "trunk" o "primary" -> ubos nga klasipikasyon) gibalik ngadto sa
sayop nga klasipikasyon. Ang sobra nga gidaghanon sa mga punoan sa punoan
ug punoan, bisan pa nga wala kaayo sila maglakaw sa daghang mga sakyanan.



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


[Talk-ca] Holger from Wheelmap in Toronto - Sep 21

2017-08-30 Per discussione Stewart C. Russell
Holger just posted this in the Toronto OSM Meetup chat:

Holger Dieterich 8:21 AM
Sent from Toronto OpenStreetMap Enthusiasts

Dear Toronto OSM enthusiasts, I'm Holger, co-founder of
http://wheelmap.org , an OSM-based app to find and mark wheelchair
accessible places. We are a non-profit organization based in Berlin but
will come to Toronto and would love to hang out with fellow OSM users.
We would like to invite you and your members for a round of beers at
Otto's Bierhalle on September 21st from 7pm. What do you think? Looking
orward to meeting you! Holger
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca


Re: [OSM-talk-fr] Distinction power line/minor_line en France

2017-08-30 Per discussione François Lacombe
Le 30 août 2017 à 15:33, Christian Quest  a écrit :

> Dans ces propositions, on oublie souvent le contributeur de base... rester
> simple permet d'avoir un potentiel plus large de contributeurs.

Certes, c'est pour ca que j'étais pas pour faire une distinction très
subjective comme celle-là.
Mais pour supprimer minor_line, il faut se lever très tôt semble-t-il.

On retrouve le même probleme sur les bornes à incendie en ce moment entre
fire_hydrant et suction_point.


Se baser sur la tension ne me semble pas une bonne idée car sur le terrain
> il n'est pas du tout évident de savoir le voltage sauf si on est un fondu
> des réseaux électriques.
>
On peut toutefois repérer les différents domaines de tension à la longueur
des isolateurs : 1m = 100kV.
En dessous de 100kV, le nombre de coupelles sur les mêmes isolateurs donne
une indication (y compris sur les caténaires SNCF).


> Par contre, les pylônes/poteaux sont un élément visuel beaucoup plus
> facile à évaluer (en gros 1 pied = pole, plusieurs pieds = tower, simpliste
> mais facile à reconnaitre pour un profane).
>
> Après si on a une majorité de pole c'est une minor_line, sinon c'est une
> line... et ensuite le voltage permet d'être au maxi de la précision (enfin,
> non, on a ensuite les circuits, etc... mais là, désolé, je décroche comme
> 99% des contributeurs).
>

Ces deux lignes ont le même impact visuel et la même fonction
http://www.openstreetmap.org/way/298000980 (poteaux)
http://www.openstreetmap.org/way/371282269 (pylônes treillis)

Aucune raison de les identifier différemment.

A partir de là, je suis pleinement d'accord pour rester simple => il
faudrait expliquer à tout ceux qui veulent taguer pour le rendu le bazar
que cela introduit dans la modélisation


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


Re: [Talk-cz] osm - turistika - android

2017-08-30 Per discussione Marián Kyral
Tak on původní dotaz nezmiňoval explicitně ČR ;-)

Já používám hlavně GDAK (keškovací aplikaci) s podklady z http://osm.paws.
cz/  Navigaci nepotřebuji, na plánování turistiky používám mozek ;-)
Pro auto občas použiji osmand.

Marián

-- Původní e-mail --
Od: Jan Martinec 
Komu: OpenStreetMap Czech Republic 
Datum: 30. 8. 2017 15:54:36
Předmět: Re: [Talk-cz] osm - turistika - android
"
Locus Pro + BRouter. Nejsem si ale jist, zda ho lze donutit, aby routoval 
přednostně po turistických trasách. 



Ad Mapy.cz: ty to sice umí, ale nemají v ČR a SR data z OSM - a jak sleduju
diskuse kolem mapování tras KČT, tak OSM byla poslední dobou nejpřesnější.




Zdar,

HPM 




Dne 30. 8. 2017 14:18 napsal uživatel "Marek Polák" :
"Mapy.cz
Marek Polák



Dne 30. srpna 2017 1:47:38 PM jzvc 
napsal:

" Zdravim vespolek,

mel bych na vas dotaz, potreboval bych nejaky hint na androidi offline
navigaci, ktera umi zobrazit a navigovat turisticke trasy. Pokud tedy
neco rozumneho existuje.

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


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

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


Re: [Talk-br] Mapeamento hidrológico

2017-08-30 Per discussione Cassio Eskelsen
A proposta de definir como "major/big/small" considero inútil e que não
agrega nada.

A outra proposta é interessante. O número de Strahler é comumente utilizado
em GIS, mas no Brasil não é tão usado já que nos acostumados com a Otto
Codificação.
A Otto Codificação é mais complexa, não sei se eles aceitariam, até pq não
se usa tanto la fora.

Cássio Rogério Eskelsen
3Geo

2017-08-30 8:20 GMT-03:00 Nelson A. de Oliveira :

> Dá uma olhada nessas propostas (que são recentes e estão sendo
> discutidas na tagging):
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/
> Waterways_classification
> https://wiki.openstreetmap.org/wiki/Proposed_features/
> Rivers_Classification
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br


Re: [Talk-br] Mapeamento hidrológico

2017-08-30 Per discussione Cassio Eskelsen
Acho que isso não é necessário, da mesma forma que não definimos
explicitamente que Rua Tal está na cidade Tal.

Cássio Rogério Eskelsen
3Geo

2017-08-30 10:00 GMT-03:00 santamariense :

> Qual a ideia de como mapear Bacias Hidrográficas? Criando relação e
> adicionando os respectivos waterways? Ou adicionando tags do tipo
> estánabacia="Bacia Hidrográfica do Aa" em cada waterway?
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br


Re: [Talk-cz] osm - turistika - android

2017-08-30 Per discussione Jan Martinec
Locus Pro + BRouter. Nejsem si ale jist, zda ho lze donutit, aby routoval
přednostně po turistických trasách.

Ad Mapy.cz: ty to sice umí, ale nemají v ČR a SR data z OSM - a jak sleduju
diskuse kolem mapování tras KČT, tak OSM byla poslední dobou nejpřesnější.

Zdar,
HPM

Dne 30. 8. 2017 14:18 napsal uživatel "Marek Polák" :

> Mapy.cz
> Marek Polák
>
>
>
> Dne 30. srpna 2017 1:47:38 PM jzvc  napsal:
>
> Zdravim vespolek,
>>
>> mel bych na vas dotaz, potreboval bych nejaky hint na androidi offline
>> navigaci, ktera umi zobrazit a navigovat turisticke trasy. Pokud tedy
>> neco rozumneho existuje.
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

2017-08-30 Per discussione marc marc
Le 30. 08. 17 à 11:42, JB a écrit :
 > Si vous faites une modification automatique,
 > vous vous limitez à la France, hein ?
Si/lorsque le programme existe, ce serrait bête
de ne pas l'utiliser ailleurs, non ?
pas une "hop corrigeons le monde", mais au cas
par cas ou un message sur la liste mondiale ou wiki
pour recenser les exceptions à la règle

Le 30. 08. 17 à 02:50, Francois Gouget a écrit :
>> vérifie sur le wiki s'il n'y a pas déjà eu un opération automatique.
> Tu veux dire sur https://wiki.openstreetmap.org ?
oui

> Je n'ai rien vu sur la page Key:phone. 
> Si c'est ailleurs je ne sais pas où chercher.
avant elles étaient toutes reprises sur
https://wiki.openstreetmap.org/wiki/Category:Automated_edits_log
mais cette page ne se met plus à jour toute seule.
Il faut chercher avec des termes genre
"Automated edits phone" et "Mechanical Edit phone"

>> Il faudrait aussi vérifier si les pages wiki sont claire à ce sujet.
>> Parce que le premier exemple que j'ai trouvé utilise iD
>> http://www.openstreetmap.org/changeset/51465606
>> le 2ieme OsmAnd http://www.openstreetmap.org/changeset/50890233
>> Leur écrire pour voir ce qui les a inciter à faire ainsi.
>> Ou tester avec la même app pour voir si c'est l'app
>> qui incite à l'erreur
> Je pense que le logiciel en tort c'est Copier/Coller. Les mappeurs ont
> dû trouver 01 02 03 04 05 sur une page de contact et comme on leur a dit
> d'internationaliser il tapent +33 espace Ctrl+V.
> Josm pourrait peut-être intégrer une vérification du champ phone mais
> encore une fois il pourrait être difficile de s'assurer qu'elle marche
> pour tous les pays.
On peux proposer l'idée à iD/OsmAnd/Maps.me/JOSM au moins pour
les numéros français à 10 chiffres et/ou essayer de faire une page wiki 
qui liste les exceptions afin que ces logiciels puissent s'en servir

>> Sinon il y a aussi sur le wiki une page où demander l'aide de scripteur
> Ah. Où ça ?
https://wiki.openstreetmap.org/wiki/FR:Modifications_automatis%C3%A9es
en bas la procédure, la discussion sur la page discussion

>> Dernier point et non des moindres, que fait-on des numéros court ?
>> le wiki sépare les numéros non pas sur leur longueur mais sur leur
>> utilisation (local ou international).
>> +331234 fonctionne-t-il en local ?
> J'ai testé de chez moi avec +33 3631. Ça marche pas.
Merci pour le test.
Du coup je propose de voir ces là séparément (clef  phone:FR)
Sauf si quelqu'un a le temps/envie de faire cela en même temps.

Le 30. 08. 17 à 03:49, Francois Gouget a écrit :
 >   * Je suis pour que le wiki ne recommande pas fortement
 > un placement particulier des espaces.
On peux préciser sur le wiki que la France et la Belgique
n'ont plus de code régionaux donc que selon la norme
c'est +33 1 23456789 même si dans la pratique c'est olé olé
OU ne mettre aucun espace et laisser l'application formater
à l'affichage.

 >   * Je suis pour que les modifications préservent
 > le formattage initial.

Cela va encore compliquer un peu plus le programme
Mais c'est le meilleur compris pour éviter de s'enliser sur le formatage

 > phone=3631 lors de l'intégration d'un bureau de poste.
Double problème.

1) si c'est appelable que depuis le pays, c'est supposé être dans 
phone:FR mais qui ne convient pas si c'est non utilisable pour le moment

2) si c'est un numéro générale pour le groupe, il ne devrait pas être 
mis comme numéro spécifique de ce bureau de poste, mais on n'a aucun 
endroit ou mettre cela (je sens que le troll des relations network
n'est pas loin) et il n'existe plus de numéro publique par bureau.

+1 pour la décision de Fred de le virer pour les futures intégrations

Le 29. 08. 17 à 22:42, osm.sanspourr...@spamgourmet.com a écrit :
 > Pour le plan de numérotation français :
 > 
https://fr.wikipedia.org/wiki/Plan_de_num%C3%A9rotation_en_France#Plan_actuel_depuis_2005
+1 mis ô puré l’enchaînement des modifs
Une page avec juste le plan actuel serrait déjà un beau nettoyage
pour tester la validité d'un numéro français
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Distinction power line/minor_line en France

2017-08-30 Per discussione Christian Quest
Se baser sur la tension ne me semble pas une bonne idée car sur le 
terrain il n'est pas du tout évident de savoir le voltage sauf si on est 
un fondu des réseaux électriques.


Par contre, les pylônes/poteaux sont un élément visuel beaucoup plus 
facile à évaluer (en gros 1 pied = pole, plusieurs pieds = tower, 
simpliste mais facile à reconnaitre pour un profane).


Après si on a une majorité de pole c'est une minor_line, sinon c'est une 
line... et ensuite le voltage permet d'être au maxi de la précision 
(enfin, non, on a ensuite les circuits, etc... mais là, désolé, je 
décroche comme 99% des contributeurs).


Dans ces propositions, on oublie souvent le contributeur de base... 
rester simple permet d'avoir un potentiel plus large de contributeurs.



Le 30/08/2017 à 11:25, marc marc a écrit :

Le 30. 08. 17 à 11:09, François Lacombe a écrit :

Je viens de re-lire le paragraphe
https://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/France#Lignes_a.C3.A9riennes

je le trouve indigeste parce qu'il bascule entre 2 critères sans qu'on
sache clairement à la fin qu'est-ce qui est unanime et qu'est-ce qui est
contesté


je souhaiterais déplacer le point line/minor_line dans la partie réseaux de 
distribution,
parce que le réseau de transport doit être à 100% décrit avec power=line.

+1
ce serrait utile d'essayer de rapprocher les 2, genre :
haute tension + gros poteau = line
basse tension + petit poteau = minor_line
et au milieu : les cas tordu qui, si j'ai bien compris, ont "2 camps",
ceux qui pensent que le classement doit se faire sur le poteau
et ceux qui pense que cela doit se faire sur le voltage
une idée du voltage entre les 2 catégories est une bonne idée même
si je suis incompétent pour savoir si 10k est mieux ou pas que 30k

avis perso, selon moi, dans la zone grise, le critère devrait être sur
le voltage/utilisation. une ligne ne peux pas être à un endroit "majeur"
et plus loin "mineur" simplement parce que localement le type de poteau
change
avis perso bis : pour moi l'utilité de minor_line c'est "à quoi
sert la ligne qui passe dans tel rue ?" et "carte du réseau
électrique transport <> distribution"
___
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] Plus aucun rapprochement entre OSM et la BANO depuis fin juillet

2017-08-30 Per discussione Christian Quest

Il y a bien un problème, mais nous sommes en pleine transition...

Petit rappel: BANO extrait ses données depuis le site web 
cadastre.gouv.fr, mais c'est un gros bricolage qui casse facilement lors 
que le site est modifié.


Les données du cadastre vont être très (très) prochainement disponibles 
sur leur forme brute et vectorielle et on n'aura plus à faire ce 
bricolage complexe et fragile.


Il me semble préférable d'investir sur l'exploitation de ces nouvelles 
données (qui permet d'aller bien plus loin que ce qu'on a fait jusqu'à 
maintenant) plutôt que de réparer un outil en fin de cycle.


Voir aussi: 
http://forum.openstreetmap.fr/viewtopic.php?f=2=1187=300#p16558




Le 30/08/2017 à 14:31, Victor/tuxayo a écrit :

Bonjour,

Quelqu'un a des infos?
https://github.com/osm-fr/bano/issues/142


À++



--
Christian Quest - OpenStreetMap France


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


Re: [OSM-talk-fr] Distinction power line/minor_line en France

2017-08-30 Per discussione François Lacombe
Le 30 août 2017 à 14:26, David Crochet  a écrit :

Un transformateur "haut de poteau" doit comporter après la transformation
> la protection, par le même appareillage, contre la surcharge du
> transformateur et contre les court-circuit de la ligne basse tension. [1].
> Ensuite l'interrupteur aérien, sur la partie haute tension, est
> généralement assuré par un poteau précédent.
>

C'est vrai, il faut surveiller la présence d'un transfo ou non.
Je pourrai ajouter cette précision sur le wiki. Parce que si tu fais ce
genre de requête overpass http://overpass-turbo.eu/s/rmk (à tort, on est
d'accord), on pourrait considérer que ce sont des interupteurs HTA et non
BT.

Pour ne laisser aucun doute, puisque sur la partie BT c'est un disjoncteur,
il faut utiliser switch=circuit_breaker puisqu'il n'y en a pas sur la haute
tension.
http://www.openstreetmap.org/node/4976704983 (ici switch=mechanical laisse
planer un gros doute)

Par contre pour la transition, pas de solution, à part indiquer le voltage
ou location:transition=minor_line pour etre sur d'indiquer que c'est la BT
qui va dans le sol.
L'intérêt d'utiliser ce tag est de ne pas avoir à connaitre la partie
souterraine, qui souvent n'est pas vérifiable ni ouverte.



> En cas de transformateur dans un élément préfabriqué, les éléments de
> protection en amont et en aval se trouvent dans des cellules à l'intérieur
> du poste préfabriqué
>

Et peuvent être indiqué sur un noeud séparé quand le poste est en cabine
(représenté comme un batiment) ou bien implicite quand c'est un poste
simplifié non accessible à l'homme (muni de design=PSSA, design=PSSB...)

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


Re: [Talk-br] Mapeamento hidrológico

2017-08-30 Per discussione santamariense
Qual a ideia de como mapear Bacias Hidrográficas? Criando relação e
adicionando os respectivos waterways? Ou adicionando tags do tipo
estánabacia="Bacia Hidrográfica do Aa" em cada waterway?

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


Re: [Talk-cz] Názvy vodních nádrží a water=reservoir

2017-08-30 Per discussione Michal Poupa
To V. n. S mezerami za tečkou


30. 8. 2017 v 13:53, jzvc :

> Dne 30.8.2017 v 9:46 Pavel Machek napsal(a):
>>> On Wed 2017-08-30 09:25:49, jzvc wrote:
>>> Dne 28.8.2017 v 22:23 Michal Poupa napsal(a):
 To právě nevím ale většinou to tak v OSM již je...
 Ve Waze to tak zadáváme.
 
 M.
 
>>> 
>>> Pokud vim, tak uz je to par patku co se resilo, ze do OSM nepatri zkratky
>>> (protoze zkratka se robotem udelat da, ale opacne ne) a v.n. je vyjadreno
>>> tagovanim, takze by to tam nemelo byt vubec.
>>> 
>>> Je to stejny, jako kdyz na tag kostela budes psat ze se to jmenuje kostel
>>> Svaty trojice ...
>>> 
>>> Tim netvrdim ze to na spouste mistech neni, ale nemelo by byt.
>> 
>> Pozor; ono tohle neni tak jednoduche.
>> 
>> Kdyz mam
>> 
>> highway=residential
>> name=Milady horakove
>> 
>> tak nedokazu urcit jestli je to "ulice Milady horakove", "trida..",
>> "bulvar..", "namesti..." nebo kdovi co jeste. Taky kostel jeste muze
>> byt... ja nevim... "bazilika", "chram", ... Vodni nadrz muze byt
>> "prehrada", "vodni dilo"...
> Oznaceni za tridu byva soucasti nazvu, ale kazda prehrada je vodni dilo, 
> pricemz ne kazde vodni dilo je prehrada. Navic to tak jako tak do name 
> nepatri, kdyz uz tak nekam do type nebo podobne.
> 
> 
>> 
>> A z tagu nepoznam kterym ze synonym se tomu kostelu rika...
> 
> Kostel z tagu poznas, do do tagu building mas zapsano misto yes prave jestli 
> je to kostel/chram/... ostatne si klikni v josm do presetu a podivej se.
> 
>> 
>>Pavel
>> 
>> 
>> 
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> 
> 
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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


[OSM-talk-fr] Plus aucun rapprochement entre OSM et la BANO depuis fin juillet

2017-08-30 Per discussione Victor/tuxayo
Bonjour,

Quelqu'un a des infos?
https://github.com/osm-fr/bano/issues/142


À++

-- 
Victor/tuxayo

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


[Talk-es] Debemos comprobar el nombre de 2800 vías.

2017-08-30 Per discussione Paloma Maria Lopez Lara

Hola de nuevo

Sí, tenéis toda la razón, a ver si logramos alguna de las dos opciones, 
o el cambio de licencia o la autorización, espero que al menos  lo 
segundo no tarde mucho,sinceramente.


saludos!

paloma




El 30/08/2017 a las 9:43, Paloma Maria Lopez Lara escribió:

Buen día

Desde Andalucía las calles pueden por ahora ir recopilándose 
apoyándonos en CDAU, es fuente de ayuntamientos, son los garantes de 
éste dato, no sé si lo veis muy /mal/ pero entiendo que puede ser una 
opción teniendo en cuenta el número de vías y el tiempo a emplear. 
También es cierto que aun CDAU no está admitido como lo está Catastro.


La licencia actualmente es :
"1. Condiciones legales de uso
La licencia de uso general a aplicar a la información del Callejero 
Digital de Andalucía Unificado (CDAU)  es la Creative Commons 
Reconocimiento 4.0 (CC BY 4.0) que implica la autorización para la 
reutilización de la información en condiciones no restrictivas, siendo 
posible la copia, distribución y comunicación pública, así como la 
producción de obras derivadas, incluso con finalidad comercial citando 
la autoría de la fuentes."

http://www.callejerodeandalucia.es/portal/web/cdau/aviso-legal

Si no,pues cada uno que aporte lo que buenamente pueda en cada ciudad.

saludos!

paloma.




--
Paloma López Lara
Servicio Gestión de la Información
Instituto de Estadística y Cartografía de Andalucía
Pabellón de Nueva Zelanda
Calle Leonardo da Vinci 21
41071 Sevilla

955 033 940

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


Re: [OSM-talk-fr] Distinction power line/minor_line en France

2017-08-30 Per discussione David Crochet

Bonjour


Le 30/08/2017 à 13:19, François Lacombe a écrit :
Mais concernant l'interrupteur et la transition, impossible de savoir 
si ils vont sur le 20kV ou pas.
On ne sera pas capable de distinguer un poteau avec transformateur 
20kV et une dérivation 20kV qui va dans le sol d'un poteau avec 
transfo 20kV et ligne BT qui part dans le sol ensuite.

Idem avec l'interrupteur

Mon idée c'est de se servir de line/minor_line pour faire cette 
distinction.


On a le cas ici : http://overpass-turbo.eu/s/rm0
http://www.openstreetmap.org/node/3992441473

Impossible de savoir si l'interrupteur est sur le 20kV ou sur la BT


Un transformateur "haut de poteau" doit comporter après la 
transformation la protection, par le même appareillage, contre la 
surcharge du transformateur et contre les court-circuit de la ligne 
basse tension. [1]. Ensuite l'interrupteur aérien, sur la partie haute 
tension, est généralement assuré par un poteau précédent.



En cas de transformateur dans un élément préfabriqué, les éléments de 
protection en amont et en aval se trouvent dans des cellules à 
l'intérieur du poste préfabriqué


Cordialement

[1] 
http://fr.electrical-installation.org/frwiki/Postes_d%E2%80%99ext%C3%A9rieur#Postes_haut_de_poteau


--
David Crochet


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


Re: [Talk-br] Mapeamento hidrológico

2017-08-30 Per discussione Sérgio V .
Jóia pessoal, bom ver que a temática hídrica encontra interesse geral.


Vamos vendo como padronizar.

A ideia do Cassio de mapear micro-bacias é importante também, e encontra 
respaldo nestas propostas que o Nelson mostrou que vem sendo levantadas no OSM 
mundial recentemente.

Imagino que possa vir a ser uma taggeamento relativamente simples.

A área de cada micro-bacia deve cobrir  relacionar-se com cada curso d'água 
(calha / rincão) até seu entroncamento com os seguintes cursos na ordem do 
fluxo (de montante a jusante), e terminar justamente no ponto de entroncamento 
com outros, seguindo a topografia dos divisores de água (pontos mais elevados / 
espigão).


E a soma de todas as micro-bacias tem que ser necessariamente igual à área da 
bacia mais ampla na qual se inserem.

Semelhante às áreas das divisões administrativas de estados e seus municípios 
(admin_level=*), onde a área do conjunto é  exatamente igual à soma das áreas 
dos membros.


Tendo associados dados de contribuição hídrica (que podem ser externos ao OSM 
ou não), permitiria facilmente levantar a contribuição de cada um isoladamente 
e de todos os membros em conjunto, fazer prognósticos, etc.


Agregando-se a área de prédios e vias (cuja área pode ser calculada 
estimadamente), permite calcular a taxa de pavimentação /  impermeabilização, 
por exemplo, e o potencial de acúmulo de água superficial.


A tag seasonal (ou outra que venha a se mostrar necessária) pode conter dados 
de recorrência.


A base de tudo é sempre o mapeamento básico de eixos de cursos d'água, e das 
áreas de bacias, sendo que esta necessita ainda de um taggeamento próprio, e 
todas em relação de waterway (talvez seja necessário ver como agregar as bacias 
nestas relações de waterway para que sejam completas).

Tendo este mapeamento básico, é relativamente simples obter ou agregar outros 
dados e fazer análises.

Obrigado pelas contribuições, vamos tocando o mapeamento básico e acompanhando 
as discussões internacionais e aqui.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Nelson A. de Oliveira 
Enviado: quarta-feira, 30 de agosto de 2017 08:20
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Mapeamento hidrológico

Dá uma olhada nessas propostas (que são recentes e estão sendo
discutidas na tagging):

https://wiki.openstreetmap.org/wiki/Proposed_features/Waterways_classification
https://wiki.openstreetmap.org/wiki/Proposed_features/Rivers_Classification

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


Re: [Talk-cz] osm - turistika - android

2017-08-30 Per discussione Marek Polák

Mapy.cz
Marek Polák



Dne 30. srpna 2017 1:47:38 PM jzvc  napsal:


Zdravim vespolek,

mel bych na vas dotaz, potreboval bych nejaky hint na androidi offline
navigaci, ktera umi zobrazit a navigovat turisticke trasy. Pokud tedy
neco rozumneho existuje.

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




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


Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr (Spain)

2017-08-30 Per discussione Frederik Ramm
Hi,

On 30.08.2017 09:29, alan_gr wrote:
> However there is confusion about the process. Several mappers on talk-es
> think that if the name of the affected streets can be verified using the
> cadastre ahead of time, this will avoid them being deleted. Some mappers
> have already started checking streets and tagging them as "source=Cadastro
> España". 

This is not what I had in mind. What I had in mind was people suggesting
a refinement to my selection process, for example telling me that "if
the name change is simply expanding Av to Avenida then you can ignore that".

I can cater for such edits as you describe and refrain from removing
names where a source tag has been added after chdr, but I don't have a
good feeling about it. I think it would be the cleanest way to delete
all names and then have them re-added, perhaps with the help of
Maproulette or similar.

> - exactly what will happen on "redaction day", including the impact on ways
> that have been edited by other mappers AFTER chdr

The current plan is to re-set the name tag to whatever it was before
chdr has edited the name (including "empty" if it was a name added by
chdr), EXCEPT where the name has meanwhile been changed by someone else,
and also EXCEPT where chdr has made primitive edits like a name expansion.

I have noticed that chdr has sometimes also added name:xx attributes
that would have to meet a similar fate.

> - approximately when "redaction day" is likely to happen

I'd say not before 15th September, but in September.

> - what mappers should do (or not do) now.

Ideally, look at a few samples from my list and check if they do indeed
represent a name that was added by chdr, and shout if they find that my
script has identified a case where chdr didn't indeed add meaningful
information.

Mikel has already identified one issue where the script didn't properly
recognize a simple "N"->"North" expansion, and there might be more.

I have uploaded a slightly reduced file that now shows the following counts:

  16331 "Mexico"
  15108 "Brazil"
  11944 "United States of America"
   6763 "RSA"
   2802 "Spain"
   2608 "Australia"
   1922 "Argentina"
   1672 "Nigeria"
   1535 "India"
   1428 "Canada"
952 "Malaysia"
744 "Botswana"
701 "Philippines"
619 "Indonesia"
553 "Italy"
414 "Turkey"
290 "Hungary"
283 "Chile"
245 "Kenya"
127 "Saudi Arabia"
107 "Paraguay"
106 "Panama"
100 "Morocco"

The counts have changed mainly for the US, and the per-state numbers
look like this:

   5150 "Arizona"
   5102 "Texas"
592 "New York"
132 "New Jersey"
129 "New Mexico"
105 "Illinois"
 96 "California"
 90 "Hawaii"
 81 "District of Columbia"
 79 "Colorado"
 61 "Iowa"
 49 "Rhode Island"
 46 "Michigan"
 27 "Nebraska"
 27 "Missouri"
 26 "Kansas"
 25 "Pennsylvania"
 20 "West Virginia"
 19 "Maryland"
 16 "Georgia"
 14 "Ohio"
 14 "Nevada"
 13 "Minnesota"
  9 "South Dakota"
  8 "Virginia"
  8 "Indiana"
  3 "Connecticut"
  1 "North Carolina"
  1 "Maine"

Bye
Frederik

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

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


Re: [OSM-talk-fr] MAJ BDOrtho ??

2017-08-30 Per discussione Stéphane Péneau

Je vais te répondre en partie de mémoire, car ça remonte à l'année dernière.

base et rover : Navspark NS-HP (GPS + Beidou) + Antenne tri-bande à 25€

Je suis resté statique 15mn et le premier fix s'est produit au bout 8mn.

Concernant la précision, je ne peux que te donner les infos fournies par 
RTKLIB, sans possibilité de comparer avec une trace de référence. En 
gros, au tout début j'ai 1 à 2 cm de précision, et ça diminue 
progressivement jusqu'à environ 10 cm. Cette diminution de la précision 
est en rapport avec la distance base<->rover qui à commencé à 0 pour 
atteindre un peu plus de 10km.


Je voudrais continuer les tests, et travailler sur cette histoire de 
réseau de base communautaire, mais je manque de temps.


Stf


Le 30/08/2017 à 12:28, marc marc a écrit :

Bonjour,

Le 29. 08. 17 à 16:27, Stéphane Péneau a écrit :

une trace en RTK

quel matériel as-tu utilisé ?
avec ou sans temps d'initialisation/stabilisation ?
quelle précision réelle penses-tu avoir obtenu ?

Cordialement,
Marc




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


Re: [Talk-cz] osm - turistika - android

2017-08-30 Per discussione majka
Ještě doplnění, protože jsem u toho Locusu zapomněla - jako navigace k tomu
využívám BRouter. Na cyklo a pěší dobré, na auto nouzovka.

2017-08-30 14:02 GMT+02:00 majka :

> Tak u androidího:
> klasika Locus, a můj osobní tip je Osmand.
> U Osmandu - stáhnout z FDroidu, stáhnout k tomu plugin vrstevnice. Mapy
> lze přes PC stáhnout čerstvé vždy začátkem měsíce nebo generovat z extraktů.
>
> Pro nás výhoda, že tam je vše co v OSM (alespoň u těch vlastnoručně
> generovaných).
>
> Turistické a cyklotrasy umí obojí.
>
> 2017-08-30 13:45 GMT+02:00 jzvc :
>
>> Zdravim vespolek,
>>
>> mel bych na vas dotaz, potreboval bych nejaky hint na androidi offline
>> navigaci, ktera umi zobrazit a navigovat turisticke trasy. Pokud tedy neco
>> rozumneho existuje.
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [Talk-cz] osm - turistika - android

2017-08-30 Per discussione majka
Tak u androidího:
klasika Locus, a můj osobní tip je Osmand.
U Osmandu - stáhnout z FDroidu, stáhnout k tomu plugin vrstevnice. Mapy lze
přes PC stáhnout čerstvé vždy začátkem měsíce nebo generovat z extraktů.

Pro nás výhoda, že tam je vše co v OSM (alespoň u těch vlastnoručně
generovaných).

Turistické a cyklotrasy umí obojí.

2017-08-30 13:45 GMT+02:00 jzvc :

> Zdravim vespolek,
>
> mel bych na vas dotaz, potreboval bych nejaky hint na androidi offline
> navigaci, ktera umi zobrazit a navigovat turisticke trasy. Pokud tedy neco
> rozumneho existuje.
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz


Re: [OSM-talk] Beach routing

2017-08-30 Per discussione joost schouppe
There are a few highway=virtual and highway:virtual=* objects, which is
intended for similar issues. See:
https://wiki.openstreetmap.org/wiki/Proposed_features/virtual_highway

I've used it a few times on pedestrian squares where a route relation
passes over the square (and it makes no sense to use the entire square, not
map a "real" highway on top of it.

I personally wouldn't call this mapping for the router. That would be like
saying we should suddenly delete the centrelines of roads if we start
mapping highway areas.

Also, shouldn't this be a tagging discussion, not talk?

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


Re: [Talk-cz] Názvy vodních nádrží a water=reservoir

2017-08-30 Per discussione jzvc

Dne 30.8.2017 v 9:46 Pavel Machek napsal(a):

On Wed 2017-08-30 09:25:49, jzvc wrote:

Dne 28.8.2017 v 22:23 Michal Poupa napsal(a):

To právě nevím ale většinou to tak v OSM již je...
Ve Waze to tak zadáváme.

M.



Pokud vim, tak uz je to par patku co se resilo, ze do OSM nepatri zkratky
(protoze zkratka se robotem udelat da, ale opacne ne) a v.n. je vyjadreno
tagovanim, takze by to tam nemelo byt vubec.

Je to stejny, jako kdyz na tag kostela budes psat ze se to jmenuje kostel
Svaty trojice ...

Tim netvrdim ze to na spouste mistech neni, ale nemelo by byt.


Pozor; ono tohle neni tak jednoduche.

Kdyz mam

highway=residential
name=Milady horakove

tak nedokazu urcit jestli je to "ulice Milady horakove", "trida..",
"bulvar..", "namesti..." nebo kdovi co jeste. Taky kostel jeste muze
byt... ja nevim... "bazilika", "chram", ... Vodni nadrz muze byt
"prehrada", "vodni dilo"...
Oznaceni za tridu byva soucasti nazvu, ale kazda prehrada je vodni dilo, 
pricemz ne kazde vodni dilo je prehrada. Navic to tak jako tak do name 
nepatri, kdyz uz tak nekam do type nebo podobne.





A z tagu nepoznam kterym ze synonym se tomu kostelu rika...


Kostel z tagu poznas, do do tagu building mas zapsano misto yes prave 
jestli je to kostel/chram/... ostatne si klikni v josm do presetu a 
podivej se.




Pavel



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




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


[Talk-cz] osm - turistika - android

2017-08-30 Per discussione jzvc

Zdravim vespolek,

mel bych na vas dotaz, potreboval bych nejaky hint na androidi offline 
navigaci, ktera umi zobrazit a navigovat turisticke trasy. Pokud tedy 
neco rozumneho existuje.


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


Re: [OSM-talk-fr] Distinction power line/minor_line en France

2017-08-30 Per discussione François Lacombe
Le 30 août 2017 à 12:21, marc marc  a écrit :

> ne manque-t-il pas le transfo HT-BT dans ta liste ?
> j'aurais cru que s'il n'y avait qu'un élément à mettre,
> ce serrait celui-là puisque les câbles HT/BT/souterrain
> sont "raccordable" au transfo
>

Si si, il faut bien mettre un transformer=distribution
Mais concernant l'interrupteur et la transition, impossible de savoir si
ils vont sur le 20kV ou pas.
On ne sera pas capable de distinguer un poteau avec transformateur 20kV et
une dérivation 20kV qui va dans le sol d'un poteau avec transfo 20kV et
ligne BT qui part dans le sol ensuite.
Idem avec l'interrupteur

Mon idée c'est de se servir de line/minor_line pour faire cette distinction.

On a le cas ici : http://overpass-turbo.eu/s/rm0
http://www.openstreetmap.org/node/3992441473

Impossible de savoir si l'interrupteur est sur le 20kV ou sur la BT


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


Re: [Talk-br] Mapeamento hidrológico

2017-08-30 Per discussione Nelson A. de Oliveira
Dá uma olhada nessas propostas (que são recentes e estão sendo
discutidas na tagging):

https://wiki.openstreetmap.org/wiki/Proposed_features/Waterways_classification
https://wiki.openstreetmap.org/wiki/Proposed_features/Rivers_Classification

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


Re: [Talk-GB] Queensferry Crossing

2017-08-30 Per discussione Derick Rethans
On Wed, 30 Aug 2017, Robert Whittaker (OSM lists) wrote:

> The new Queensferry Crossing opened this morning. There's an article
> at http://www.bbc.co.uk/news/uk-scotland-41081556 with people
> complaining that the new bridge doesn't appear in Google maps yet.
> Although OS says they've added it to their MasterMap database, it's
> not yet on e.g.
> https://osmaps.ordnancesurvey.co.uk/55.99866,-3.40057,14 . It's also
> not yet on Bing maps.
> 
> On OSM, the bridge is mostly there, but some of the link roads at the
> north end are still marked as highway=construction. Does anyone have
> enough local knowledge to be able to fix these up correctly? There's a
> chance for a bit of publicity if OSM is the only mapping provider to
> have the bridge in place on the day it opens.

The Scottish Government has this on it:
https://www.transport.gov.scot/projects/forth-replacement-crossing/forth-replacement-crossing/#1325

cheers,
Derick

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


Re: [OSM-talk-fr] Création de la liste OSM tagging-fr - communication - fragmentation

2017-08-30 Per discussione Christian Rogel


Le 30 août 2017 à 12:36, quicky  a écrit :
> Ca existe depuis des anneees pour les mailing listes Openstreetmap.
> Il te suffit d aller ici et tu verras toutes les mailing listes du projet
> presentees sous forme de forum
> http://gis.19327.n8.nabble.com/OpenStreetMap-f5171240.html
> y compris talk-fr
> http://gis.19327.n8.nabble.com/France-f5380434.html



C'est là qu'on voit la confusion un peu gonflante : Talk-fr a été créée comme 
un pendant à la liste Talk-en (indicatifs habituels de langue), mais, a été 
confinée dans l'esprit des gens à la RF. Elle est ravalée au niveau de la GB.
Pour moi, il y a nécessité de le réaffirmer son statut international, puisque 
les pratiques OSM sont homogènes, indépendamment de la langue véhiculaire.

Christian

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


Re: [OSM-talk-fr] Création de la liste OSM tagging-fr - communication - fragmentation

2017-08-30 Per discussione quicky
> Je me demandais dans un précédent email si justement il ne faudrait
> pas rapprocher les 2, cad que mailing list et forum ne soient
> que 2 interfaces vers la même chose.
> chacun choisit son interface préférée en fonction de ses critères. 

Salut,

Ca existe depuis des anneees pour les mailing listes Openstreetmap.
Il te suffit d aller ici et tu verras toutes les mailing listes du projet
presentees sous forme de forum
http://gis.19327.n8.nabble.com/OpenStreetMap-f5171240.html
y compris talk-fr
http://gis.19327.n8.nabble.com/France-f5380434.html



--
View this message in context: 
http://gis.19327.n8.nabble.com/Creation-de-la-liste-OSM-tagging-fr-communication-fragmentation-tp5901600p5901747.html
Sent from the France mailing list archive at Nabble.com.

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


Re: [OSRM-talk] Travel duration not realistic

2017-08-30 Per discussione Richard Saba
Thank You Frédéric for this interesting idea.

I guess land usage is a database stored information by default ?

Do you have any testing results that ensure duration is then close to reality 
or at least to Google Maps ? 

Before i consider integrating your code, do You know which parameters are to 
check in the profiles in order to be sure that a MINIMUM realistic 
configuration is done ?
In other words, knowing that my starting point is OSRM 5.3.0 with standard .lua 
profiles, is there any specific settings to check in order to be sure that all 
possible parameters are taken into account ( penalties, road lanes, etc..)

Regards,


























  
 
 
 
-Message d'origine-
De : Frédéric Rodrigo [mailto:fred.rodr...@gmail.com] 
Envoyé : mercredi 30 août 2017 11:54
À : Mailing list to discuss Project OSRM ; Richard 
Saba 
Objet : Re: [OSRM-talk] Travel duration not realistic

Le 30/08/2017 à 11:17, Richard Saba a écrit :
>
> Hi,
>
> When computing a route and its duration between two points in a big 
> city, duration result is not realistic.
>
> In Paris for example, a straight road of 1km takes less than 1 mn to 
> be crossed.
>
> Google maps, proposes 5 mn which is more close to reality values.
>
> Beside taking into account real time traffic info, could you please 
> help setting a solution to enhance those results ?
>
> If I well understood, I have to try different values for tags like 
> speed, maxspeed, penalties etc...
>
> Is there anyone who already did some tests for this topic ?
>
> Which tag to modify first, especially in the example I provided ?
>
> Is there any influence for data, like roads attributes ? Example, 
> maxspeed for motorways is set in the profile but some motorways have 
> different speed.
>
> So I wonder if OSM data includes such information and if osrm takes 
> this into account.
>

It is the problem with OSM about traffic realistic speed. OSM it self does not 
have the data. Mapbox use telemetric traffic data to improve the result. But 
this kind of data are not openly available.
On my side I choose to use density of the area to adjust the speed, code is 
available on contrib: 
https://github.com/Project-OSRM/osrm-profiles-contrib/tree/master/5/9/urban-density
(I have the port for v5.11.0 ready at home).

Regards.


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


Re: [OSM-talk-fr] Création de la liste OSM tagging-fr - communication - fragmentation

2017-08-30 Per discussione THEVENON Julien


De : marc marc 

> Je me demandais dans un précédent email si justement il ne faudrait
> pas rapprocher les 2, cad que mailing list et forum ne soient
> que 2 interfaces vers la même chose.
> chacun choisit son interface préférée en fonction de ses critères.

Salut,

Ca existe depuis des annees pour les mailings listes OSM y compris talk-fr, si 
tu suis le lien tu verras les mailing listes sous une forme de forum

http://gis.19327.n8.nabble.com/OpenStreetMap-f5171240.html

Julien

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


Re: [OSM-talk-fr] Création de la liste OSM tagging-fr - communication - fragmentation

2017-08-30 Per discussione Muselaar



Le 30/08/2017 à 10:57, marc marc a écrit :

Le 30. 08. 17 à 10:20, Christian Quest a écrit :

Le forum est une autre approche complémentaire

je trouve que le forum et la mailing list ont des approches
complémentaires. tu trouves l'un dépassé, moi je trouve l'inverse
(un email par message, lire/répondre y compris sur smartphone, etc)

+1
Sur une mailing-list, je reçois tous les messages dans mon courrielleur, 
qui est le centre de mon utilisation informatique, et je les lis quand 
je veux, je vois passer les titres des messages. Sur un forum, je 
décroche toujours au bout d'un moment, parce que j'arrête d'aller y 
voir. Et je ne connais pas de présentation de forum où l'on voie les 
messages (je dis bien les messages, et non les sujets) sous forme de 
liste, avec une ligne par item. C'est plutôt un écran par message… Ce 
qui me gonfle très vite, surtout s'il y a 50 messages par jour, dans 
plein de sous-forums impossibles à parcourir. Et la présentation des 
mailing-lists dépend de mon paramétrage perso sur mon ordinateur, ce qui 
n'est pas le cas d'un forum.

Je me demandais dans un précédent email si justement il ne faudrait
pas rapprocher les 2, cad que mailing list et forum ne soient
que 2 interfaces vers la même chose.
chacun choisit son interface préférée en fonction de ses critères.

autre point que j'évoquais : utilité ou non de résumer les longs
échanges afin que ceux qui veulent zaper les discussions puisse
quand même connaître le résumé
à voir sous quelle forme : email de résumé ou 2-3 lignes dans weeklyOsm

+1 aussi, du fait.

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


Re: [Talk-GB] Queensferry Crossing

2017-08-30 Per discussione me
On 30/08/17 at 10:28am, Tom Hughes wrote:
> On 30/08/17 10:26, Tom Hughes wrote:
> 
> > As best I can tell from wikipedia the new bridge is the M90 and under
> > motorway conditions with the old bridge presumably expected to carry
> > non-motorway traffic as the A9000.
> 
> So from http://www.bbc.co.uk/news/uk-scotland-edinburgh-east-fife-41086779
> it seems it is non-motorway for now but will become a motorway once the old
> bridge has been "adapted for public transport".

I am just double checking things now. As far as I can make out the new
bridge is as Tom said the M90 but with a 40mph speed limit until
October. 

To make things more complicated the Queensferry Crossing is open for 2
days, then closed for 6 before re-opening. My thinking is to leave it as
open rather than close it for 6 days. 

The old bridge is effectively closed to all motor traffic, until
October/November... 

Usefully one of the colleagues filmed the crossing this morning:
https://www.youtube.com/watch?v=25SdGmTPlf0

Cheers
Chris

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


[OSM-talk-fr] traduction shop=boutique shop=fashion

2017-08-30 Per discussione marc marc
Sur la mailing mondiale, Simon essaye de mettre de l'ordre
l'un des points est le faux-ami "boutique" qui est traduit
à toutes les sauces en français

Lisez la page anglaise ou au moins la photo et la page wikipedia
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dboutique
https://en.wikipedia.org/wiki/Boutique
Comment selon vous faudrait-il traduire cela en Français ?
j'ai proposé "magasin de Haute couture"

autre problème de traduction shop=fashion
j'ai proposé : "magasin de vêtements et accessoires de mode"

Et vous comment traduiriez vous ces 2 termes ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-GB] Queensferry Crossing

2017-08-30 Per discussione alasdair
I drove over it this morning so have local knowledge if you need it.
(not sure where you are Chris)

  Al.
On 30/08/2017 10:45, Chris Fleming wrote:

> I am just checking over it now. 
> 
> On Wed, 30 Aug 2017, 10:30 Tom Hughes  wrote: 
> 
>> On 30/08/17 10:26, Tom Hughes wrote:
>> 
>>> As best I can tell from wikipedia the new bridge is the M90 and under
>>> motorway conditions with the old bridge presumably expected to carry
>>> non-motorway traffic as the A9000.
>> 
>> So from
>> http://www.bbc.co.uk/news/uk-scotland-edinburgh-east-fife-41086779 it
>> seems it is non-motorway for now but will become a motorway once the old
>> bridge has been "adapted for public transport".
>> 
>> Tom
>> 
>> --
>> Tom Hughes (t...@compton.nu)
>> http://compton.nu/
>> 
>> ___
>> 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-it] Wikigita con mappatura a Santo Stefano Magra (SP) 23 settembre

2017-08-30 Per discussione Alessandro Palmas
Nei prossimi appuntamenti OSM 
https://wiki.openstreetmap.org/wiki/Main_Page ho aggiunto la Wikigita a 
Santo Stefano Magra (SP) prevista per sabato 23 settembre.


Durante la giornata, organizzata in occasione di Wiki Loves Monuments, 
oltre a visitare il Museo dei Trasporti Autofilotranviari miglioreremo 
la mappatura OSM dei dintorni che ne ha tanto bisogno.


Se c'è qualche mappatore in zona o anche chi vorrebbe capire come 
funziona OSM è il benvenuto. Chiediamo di registrarsi alla seguante 
pagina 
https://it.wikipedia.org/wiki/Wikipedia:Raduni/Wikigita_a_Santo_Stefano_Magra 
(o di scriverlo qui in lista).


Alessandro Ale_Zena_IT


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


Re: [OSM-talk-fr] Distinction power line/minor_line en France

2017-08-30 Per discussione François Lacombe
Le 30 août 2017 à 11:25, marc marc  a écrit :

> je le trouve indigeste parce qu'il bascule entre 2 critères sans qu'on
> sache clairement à la fin qu'est-ce qui est unanime et qu'est-ce qui est
> contesté
>
Oui, pas de consensus. Donc on ne peut qu’émettre des conseils
Ok pour le rendre un peu plus clair, et surtout n'indiquer ce manque de
consens que sur la distribution et pas le transport.


>
> > je souhaiterais déplacer le point line/minor_line dans la partie réseaux
> de distribution,
> > parce que le réseau de transport doit être à 100% décrit avec power=line.
>
> avis perso, selon moi, dans la zone grise, le critère devrait être sur
> le voltage/utilisation. une ligne ne peux pas être à un endroit "majeur"
> et plus loin "mineur" simplement parce que localement le type de poteau
> change
> avis perso bis : pour moi l'utilité de minor_line c'est "à quoi
> sert la ligne qui passe dans tel rue ?" et "carte du réseau
> électrique transport <> distribution"
>
C'est un des axes mais pas le seul. Certains souhaitent juste faire la
distinction juste pour mettre un trait plus finsur le rendu.
Comme toi je pense qu'une ligne d'importance ne devient pas insignifiante
au milieu juste parce que les supports sont plus anciens ou plus petits.


Le 30 août 2017 à 11:45,  a écrit :

>
> Je reste encore trop franco-français, mais la limite à " inférieur à 50 kV
> " me semblais plus judicieux, puisque c'est la limite (en france) entre la
> HTA et la HTB selon le Décret 95-608 du 6 mai 1995.
>
Le but est de ne discuter que sur le cas Français pour commencer.
Il y a des limites partout, mais est-ce que celle entre la HTA et HTB est
la plus judicieuse à considérer ?


> Ensuite l'IEC 60038 parle de limite à 35 kV.
>
> D'où la question, avons-nous des équipement entre 35kv et 50 kV ? Si oui,
> c'est galère, sinon, on met la limite à 35 kV comme l'indique la norme
> internationale
>

Oui, il reste des lignes RTE, de transport donc, à 42 kV
Pire : certaines lignes RTE à 42kV ont été rétrocédées à la distribution en
20kV comme ici : http://www.openstreetmap.org/way/517446289
https://www.google.fr/maps/@45.3481164,6.3074121,3a,21.5y,340.6h,100.36t/data=!3m7!1e1!3m5!1sIerETOKiRD99vjFtuXGdNw!2e0!6s%2F%2Fgeo3.ggpht.com%2Fcbk%3Fpanoid%3DIerETOKiRD99vjFtuXGdNw%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D77.04886%26pitch%3D0%26thumbfov%3D100!7i13312!8i6656
Visuellement ce serait une power=line, mais dans l'exploitation une
prétendue "minor".

Descendre la limite entre HTA (20/15 kV) et BT (400V) ne laisse plus de
place à l'hésitation
Je ne connais pas le cas de lignes HT converties à la BT, ni l'inverse
d'ailleurs

Et surtout penser à ces cas là :
https://www.google.fr/maps/@45.9888313,6.1386526,3a,75y,300.72h,101.13t/data=!3m6!1e1!3m4!1swv2jJXgYcuHTN9XnK_rmfQ!2e0!7i13312!8i6656
Sur le même poteau on a:
- Extrémité de ligne 20 kV
- Interrupteur BT
- Extrémités de lignes BT
- Transition aéro-souterraine BT (qui ne concerne d'aucune sorte le 20 000
V)

Pouvoir signifier que c'est la transition et l'interrupteur sont sur la BT
via minor_line serait une grosse avancée

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


Re: [OSM-talk] Beach routing

2017-08-30 Per discussione Richard
On Tue, Aug 29, 2017 at 12:53:43PM +0100, Philip Barnes wrote:
> This really needs routers to be able to route over areas, the same issue 
> exists over large areas of grass such as found in parks or town squares.

in many parts of the world such areas are actually "dont walk there",
before routers start routing them they awould have to be tagged with 
access tags.

Also grass areas in the mountains can't be assumed to be walkable.

Richard


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


Re: [OSRM-talk] Travel duration not realistic

2017-08-30 Per discussione Frédéric Rodrigo

Le 30/08/2017 à 11:17, Richard Saba a écrit :


Hi,

When computing a route and its duration between two points in a big 
city, duration result is not realistic.


In Paris for example, a straight road of 1km takes less than 1 mn to 
be crossed.


Google maps, proposes 5 mn which is more close to reality values.

Beside taking into account real time traffic info, could you please 
help setting a solution to enhance those results ?


If I well understood, I have to try different values for tags like 
speed, maxspeed, penalties etc...


Is there anyone who already did some tests for this topic ?

Which tag to modify first, especially in the example I provided ?

Is there any influence for data, like roads attributes ? Example, 
maxspeed for motorways is set in the profile but some motorways have 
different speed.


So I wonder if OSM data includes such information and if osrm takes 
this into account.




It is the problem with OSM about traffic realistic speed. OSM it self 
does not have the data. Mapbox use telemetric traffic data to improve 
the result. But this kind of data are not openly available.
On my side I choose to use density of the area to adjust the speed, code 
is available on contrib: 
https://github.com/Project-OSRM/osrm-profiles-contrib/tree/master/5/9/urban-density 
(I have the port for v5.11.0 ready at home).


Regards.


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


Re: [Talk-cz] Názvy vodních nádrží a water=reservoir

2017-08-30 Per discussione Marián Kyral
A dá se to nějak porovnat s katastrem?

Třeba přehrada Olešná u FM, se dle katastru oficiálně jmenuje "VODNÍ NÁDRŽ
OLEŠNÁ"
V OSM to je jako v.n. Olešná: https://openstreetmap.cz/#map=18/49.65910/
18.31473=dX

Přitom pro většinu místních to vždy byla a bude přehrada Olešná.

Jinak proti rozvinutí zkratek nic nemám, v OSM se doporučuje zkratkám se
vyhýbat. Případně je můžeme dát do short_name: https://wiki.openstreetmap.
org/wiki/Key:name

Tedy:
name=Vodní nádrž Olešná
short_name=v.n. Olešná
alt_name=přehrada Olešná  (nebo loc_name=?)

Marián

-- Původní e-mail --
Od: Michal Poupa 
Komu: OpenStreetMap Czech Republic 
Datum: 30. 8. 2017 10:54:05
Předmět: Re: [Talk-cz] Názvy vodních nádrží a water=reservoir
"Tech v. n. je tam hodně ale podle mne není problém dát robotem to na Vodní
nádrž stačí jednoduchý filter

water=reservoir a hledat všechny kombinace skratky v názvu bez mezer s z
mezerami a malá velká písmena. Takže nevidím jediný problém proč by robotem
nešla odstranit zkratka.

Michal


30. 8. 2017 v 9:46, Pavel Machek :

>> On Wed 2017-08-30 09:25:49, jzvc wrote:
>> Dne 28.8.2017 v 22:23 Michal Poupa napsal(a):
>>> To právě nevím ale většinou to tak v OSM již je...
>>> Ve Waze to tak zadáváme.
>>>
>>> M.
>>>
>>
>> Pokud vim, tak uz je to par patku co se resilo, ze do OSM nepatri zkratky
>> (protoze zkratka se robotem udelat da, ale opacne ne) a v.n. je vyjadreno
>> tagovanim, takze by to tam nemelo byt vubec.
>>
>> Je to stejny, jako kdyz na tag kostela budes psat ze se to jmenuje kostel
>> Svaty trojice ...
>>
>> Tim netvrdim ze to na spouste mistech neni, ale nemelo by byt.
>
> Pozor; ono tohle neni tak jednoduche.
>
> Kdyz mam
>
> highway=residential
> name=Milady horakove
>
> tak nedokazu urcit jestli je to "ulice Milady horakove", "trida..",
> "bulvar..", "namesti..." nebo kdovi co jeste. Taky kostel jeste muze
> byt... ja nevim... "bazilika", "chram", ... Vodni nadrz muze byt
> "prehrada", "vodni dilo"...
>
> A z tagu nepoznam kterym ze synonym se tomu kostelu rika...
>
> Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/
blog.html
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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


Re: [Talk-GB] Queensferry Crossing

2017-08-30 Per discussione Chris Fleming
I am just checking over it now.

On Wed, 30 Aug 2017, 10:30 Tom Hughes  wrote:

> On 30/08/17 10:26, Tom Hughes wrote:
>
> > As best I can tell from wikipedia the new bridge is the M90 and under
> > motorway conditions with the old bridge presumably expected to carry
> > non-motorway traffic as the A9000.
>
> So from
> http://www.bbc.co.uk/news/uk-scotland-edinburgh-east-fife-41086779 it
> seems it is non-motorway for now but will become a motorway once the old
> bridge has been "adapted for public transport".
>
> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
>
> ___
> 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] Distinction power line/minor_line en France

2017-08-30 Per discussione david . crochet
Bonjour

- Mail original -
De: "François Lacombe" 


Initialement partisan de l'abandon pur et simple de minor_line, je pense au 
compromis suivant: 
Compte tenu des distances imposées par les tensions auxquelles les lignes 
aériennes sont exploitées, minor_line ne saurait être utilisé sur des lignes > 
30 000 volts. 
Ce serait évidemment beaucoup mieux, au niveau français, d'établir une limite 
ferme à 10 000 volts 
Au dessus de cette limite les lignes deviennent visuellement impactantes et de 
bons éléments pour s'orienter. C'est donc un débat 100% distribution. 
- Mail original -

Je reste encore trop franco-français, mais la limite à " inférieur à 50 kV " me 
semblais plus judicieux, puisque c'est la limite (en france) entre la HTA et la 
HTB selon le Décret 95-608 du 6 mai 1995.

Ensuite l'IEC 60038 parle de limite à 35 kV.

D'où la question, avons-nous des équipement entre 35kv et 50 kV ? Si oui, c'est 
galère, sinon, on met la limite à 35 kV comme l'indique la norme internationale

Cordialment

-- 
David Crochet

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


Re: [OSM-talk-fr] Stations service rue de Rivoli

2017-08-30 Per discussione Frédéric Rodrigo

J'ai exclus les points avec ces coordonnées.
Ça sera pris en compte avec les prochaines mise à jour code d'Osmose.

Frédéric.


Le 27/08/2017 à 23:50, Francois Gouget a écrit :

Osmose signale les stations service pour lequelles on dispose
d'information en OpenData mais pour lesquelles on n'a pas d'objet dans
OpenStreetMap.

Normalement ces signalements sont faits à l'endroit ou est censée se
trouver la station service. Mais rue de Rivoli il semble y avoir des
dizaines de ces signalements, tous superposés, aucun n'étant censé se
trouver à Paris :

https://osmose.openstreetmap.fr/fr/map/#item=8200=18=48.859046=2.34734=Mapnik=T


Je n'ai pas l'impression que les coordonnées du fichier en OpenData
soient fausses (du moins pas plus que d'habitude). Alors que s'est-il
passé ? Un bug du script ? Un bug déjà corrigé mais qui nécessiterait de
faire le ménage dans la base pour forcer la recréation de ces
signalements au bon endroit ?


Toujours sur ce sujet dans Osmose, juste sous " Station service,
intégration possible", il faudrait corriger le menu "no translation"
pour qu'il s' appelle quelque chose comme "Station service, à mettre à
jour".



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


Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

2017-08-30 Per discussione JB

Le 30/08/2017 à 11:36, Francois Gouget a écrit :

On Tue, 29 Aug 2017, marc marc wrote:
Le 29. 08. 17 à 04:31, Francois Gouget a écrit :

je ne connais pas trop le format des numéros de téĺéphone
dans les autres pays.

le format est international:)

Je voulais dire que je ne sais pas s'il faut enlever le 0 pour les
autres pays. Apparemment il ne faut pas pour l'Italie.
Euh, juste pour me rassurer : Si vous faites une modification 
automatique, vous vous limitez à la France, hein ?
Déjà chez nous on n'est pas sûr d'être d'accord, mais si en plus on va 
mettre le bordel chez les voisins…

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


Re: [Talk-it] [Desiderata] HW per servizi

2017-08-30 Per discussione Cascafico Giovanni
> Vedendo diversi servizi e non avendo molto tempo per analizzarli tutti ho
> alcune difficoltà a capire soprattutto l'usabilità dei singoli servizi e le
> differenze tra i vari Achavi, questo servizio che non conoscevo e il
> 'Bollettino delle cancellazioni' (1) del nostro Geofrizz
>
> Rifacendomi anche alla mail di alcuni giorni fa "User che cancella
> stradine di servizio" penso che un servizio che possa 'scavare' alla
> ricerca di cancellazioni e vandalismi possa essere utile. Allo stesso tempo
> dovrebbe essere comprensibile e utilizzabile da molti utenti.
>
> Aiutatemi a capire please :-)
>
>
OSM analytic tracker non è un bollettino delle cancellazioni.

Il changeset con modifiche arbitrarie è difficilmente identificabile da uno
con modifiche normali. questo OSM analytic tracker evidenzia (oltre ai
soliti creazione//modifica/cancellazione) i valori delle chiavi prima e
dopo e lo fa in una pagina di testo ("list of changesets with analytic
details" [1]) che si e' dimostrata utile per identificare rapidamente
vandalismi dissimulati.

diversamente da achavi, non è necessario cliccare sulla mappa ed è
possibile definire oltre alla bbox di default anche un poligono di
interesse;

diversamente da achavi, non è adatto per ricercare in un ampio arco
temporale (i revert risulterebbero complessi), ma per isolare rapidamente i
vandalismi in atto ed in una regione definita, da cui la frase "Improve
team spirit of a regional OSM team/task-force".


[1] https://github.com/MichaelVL/osm-analytic-tracker
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

2017-08-30 Per discussione Francois Gouget
On Tue, 29 Aug 2017, marc marc wrote:

> Le 29. 08. 17 à 04:31, Francois Gouget a écrit :
> > je ne connais pas trop le format des numéros de téĺéphone
> > dans les autres pays.
> 
> le format est international :)

Je voulais dire que je ne sais pas s'il faut enlever le 0 pour les 
autres pays. Apparemment il ne faut pas pour l'Italie.


> Jean-Marc Liotier à écrit
>  > laissons à la couche de présentation le privilège de
>  > formater à sa fantaisie.
> +1
> 
> Mais faut d'abord supprimer la source du problème.
> François tu t'en charge ?

Pas sûr d'avoir le temps. C'est bien le problème.


-- 
Francois Gouget   http://fgouget.free.fr/
  Hiroshima '45 - Czernobyl '86 - Windows '95___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] MAJ BDOrtho ??

2017-08-30 Per discussione François Lacombe
Hello,

Je profite de la discussion pour demander si on peut accéder à d'anciennes
versions de la BDOrtho ?
Sans parler de la machine à remonter le temps du Géoportail, ce pourrait
être sympa d'avoir des vues aériennes du début 2000 ou fin 90 de certaines
zones.

Un ou plusieurs TMS serait un luxe insolent, mais je ne désespère pas ;)

François

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 

Le 29 août 2017 à 16:45, HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT
GE APPUI PERFORMANCE)  a écrit :

> Il ne faut pas oublier des IDG qui annoncent leurs collaborations avec
> l'IGN en matière, entre autres, de production de l'orthophotoplan.
> CIGAL dans le Grand Est par exemple : https://www.cigalsace.org/
> geonetwork/apps/georchestra/
>
> Denis
>
>
> -Message d'origine-
> De : Stéphane Péneau [mailto:stephane.pen...@wanadoo.fr]
> Envoyé : mardi 29 août 2017 16:27
> À : Discussions sur OSM en français 
> Objet : [OSM-talk-fr] MAJ BDOrtho ??
>
> Bonjour,
>
> Certains auraient remarqué une mise à jour de l'imagerie aérienne de la
> BDOrtho ?
>
> Moi oui, depuis aujourd'hui, au moins sur le sud de la loire-atlantique.
>
> D'ailleurs, j'avais tracé un nouveau giratoire depuis une trace en RTK, et
> la correspondance est pas mal du tout :
> https://www.openstreetmap.org/way/371573209
>
> Stf
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> ---
> Ce message et toutes les pièces jointes sont établis à l'intention
> exclusive de ses destinataires et sont confidentiels. L'intégrité de ce
> message n'étant pas assurée sur Internet, la SNCF ne peut être tenue
> responsable des altérations qui pourraient se produire sur son contenu.
> Toute publication, utilisation, reproduction, ou diffusion, même partielle,
> non autorisée préalablement par la SNCF, est strictement interdite. Si vous
> n'êtes pas le destinataire de ce message, merci d'en avertir immédiatement
> l'expéditeur et de le détruire.
> ---
> This message and any attachments are intended solely for the addressees
> and are confidential. SNCF may not be held responsible for their contents
> whose accuracy and completeness cannot be guaranteed over the Internet.
> Unauthorized use, disclosure, distribution, copying, or any part thereof is
> strictly prohibited. If you are not the intended recipient of this message,
> please notify the sender immediately and delete it.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-GB] Queensferry Crossing

2017-08-30 Per discussione Tom Hughes

On 30/08/17 10:26, Tom Hughes wrote:

As best I can tell from wikipedia the new bridge is the M90 and under 
motorway conditions with the old bridge presumably expected to carry 
non-motorway traffic as the A9000.


So from 
http://www.bbc.co.uk/news/uk-scotland-edinburgh-east-fife-41086779 it 
seems it is non-motorway for now but will become a motorway once the old 
bridge has been "adapted for public transport".


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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


Re: [OSM-talk-fr] Bornes à incendie : proposition en cours d'écriture

2017-08-30 Per discussione François Lacombe
Le 28 août 2017 à 11:32, marc marc  a écrit :

> Je trouve que ce n'est pas exact.
> capacity indique le maximum possible pour une infrastructure.
> le chiffre indiqué sur une borne incendie n'est pas son débit
> variable dans le temps (celui là ne dépend que du pompier)
> mais le débit maximum dont la borne est capable.
>
Je suis de cet avis, mais tout le monde n'entend pas cette logique.
Ils ont migré vers flow_rate, ce qui est déjà un progrès.


> On fait quoi pour la séparation pressurisé <> non pressurisé ?
> j'argumente une dernière fois avec le fait que 10% des bornes françaises
> vont se trouver dans un état indéterminée pas d'info pour les classer ?
> et surtout quid à l'avenir du gars qui rencontre une borne
> sans plaque de pression... il doit choisir l'une des 2 catégories,
>

Pareillement, je suis de ton avis.
dans l'immédiat, avoir des clés agnostiques de fire_hydrant ou
suction_point est déjà une avancée.
On peut partir la dessus pour l'instant et dans un second temps revenir en
force avec des cas et propositions dans ce sens ?
Comme tu le disais, sinon ca risque d'échouer si on fait tout en même temps


>
>  > attends tu l'avis Bhynoteam ?
>  >
>  > Yann Kacenelen m'a répondu sur Twitter avec ce document qu'il avait
>  > rédigé en 2015
>  > https://framagit.org/ykacenelen/point_eau_incendie_OSM/snippets/655
> J'ai lu son document.
> ä un endroit il dit qu'il n'est pas pour type=pond
> ä un autre il propose l'ajout de type=dry_hydrant qui n'est
> cependant pas en jaune comme le reste des nouveauté proposé.
> je ne sais pas si l'un est un remplacement de l'autre.
> En fin de pdf, il utilise donne des exemples de bornes sans pression :
> emergency = fire_hydrant
> fire_hydrant:type = pillar
> fire_hydrant:pressure = suction
> Donc j'en déduit que selon lui, il faudrait aussi supprimer le "pond"
> mais que le critère d'uneborne n'est pas la pression
> il ne compte pas participer au débat ?
>
Non à mon avis il n'a pas le temps
Le document étant principalement en phase avec la proposition hormis les
clés avec fire_hydrant: de partout, je suis d'avis pour le soutenir en
l'état.

Il reste peut-être un point sur couplings_type et couplings_diameter qui
sont là pour décrire les types de connexion et surtout leur nombre et
diamètre.
Peut-être suggérerais-je l'ajout de manufacturer=* et model=* qui
pourraient servir à connaitre le modele de borne (standard dans le
catalogue fournisseur) sans avoir à préciser exactement les diamètres et
types de connexion (pas forcément visibles en plus)
Alors que des fabricants il n'y en a pas des masses (bayard,...)

Les points Resolved commencent à apparaitre dans le Talk, ce qui est bon
signe

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


[Talk-it] società e-commerce

2017-08-30 Per discussione demon.box
ciao, come taggo la sede di una società che vende esclusivamente su internet
(quindi e-commerce) e non è perciò aperta al pubblico ma vi si possono
esclusivamente ritirare i prodotti acquistati senza pagare le spese di
spedizione?
grazie
--enrico




--
View this message in context: 
http://gis.19327.n8.nabble.com/societa-e-commerce-tp5901726.html
Sent from the Italy General mailing list archive at Nabble.com.

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


Re: [Talk-GB] Queensferry Crossing

2017-08-30 Per discussione Tom Hughes

On 30/08/17 09:46, Robert Whittaker (OSM lists) wrote:


On OSM, the bridge is mostly there, but some of the link roads at the
north end are still marked as highway=construction. Does anyone have
enough local knowledge to be able to fix these up correctly? There's a
chance for a bit of publicity if OSM is the only mapping provider to
have the bridge in place on the day it opens.


There seems to be come confusion over status as well - much of it has a 
ref of M90 but is highway=trunk while the link road to the south has a 
ref of A90 instead.


Meanwhile the old bridge was changed from A90 to A9000 last night but is 
still part of a relation labelled A90 which may be what is causing the 
labelling to flip back and forth or that might just be old tiles.


As best I can tell from wikipedia the new bridge is the M90 and under 
motorway conditions with the old bridge presumably expected to carry 
non-motorway traffic as the A9000.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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


Re: [OSM-talk-fr] Distinction power line/minor_line en France

2017-08-30 Per discussione marc marc
Le 30. 08. 17 à 11:09, François Lacombe a écrit :
> Je viens de re-lire le paragraphe 
> https://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/France#Lignes_a.C3.A9riennes
>  
je le trouve indigeste parce qu'il bascule entre 2 critères sans qu'on 
sache clairement à la fin qu'est-ce qui est unanime et qu'est-ce qui est 
contesté

> je souhaiterais déplacer le point line/minor_line dans la partie réseaux de 
> distribution,  
> parce que le réseau de transport doit être à 100% décrit avec power=line.
+1
ce serrait utile d'essayer de rapprocher les 2, genre :
haute tension + gros poteau = line
basse tension + petit poteau = minor_line
et au milieu : les cas tordu qui, si j'ai bien compris, ont "2 camps", 
ceux qui pensent que le classement doit se faire sur le poteau
et ceux qui pense que cela doit se faire sur le voltage
une idée du voltage entre les 2 catégories est une bonne idée même
si je suis incompétent pour savoir si 10k est mieux ou pas que 30k

avis perso, selon moi, dans la zone grise, le critère devrait être sur 
le voltage/utilisation. une ligne ne peux pas être à un endroit "majeur" 
et plus loin "mineur" simplement parce que localement le type de poteau 
change
avis perso bis : pour moi l'utilité de minor_line c'est "à quoi
sert la ligne qui passe dans tel rue ?" et "carte du réseau
électrique transport <> distribution"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[OSRM-talk] Travel duration not realistic

2017-08-30 Per discussione Richard Saba
Hi,

When computing a route and its duration between two points in a big city, 
duration result is not realistic.
In Paris for example, a straight road of 1km takes less than 1 mn to be crossed.
Google maps, proposes 5 mn which is more close to reality values.

Beside taking into account real time traffic info, could you please help 
setting a solution to enhance those results ?

If I well understood, I have to try different values for tags like speed, 
maxspeed, penalties etc...
Is there anyone who already did some tests for this topic ?
Which tag to modify first, especially in the example I provided ?
Is there any influence for data, like roads attributes ? Example, maxspeed for 
motorways is set in the profile but some motorways have different speed.
So I wonder if OSM data includes such information and if osrm takes this into 
account.



Best Regards,

Richard

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


[OSM-talk-fr] Distinction power line/minor_line en France

2017-08-30 Per discussione François Lacombe
Hello à tous,

TL;DR : abaissons au niveau français la limite entre power=minor_line et
power=line à 10 000 volts.
- Pour taguer le 20 000 vols et la base tension sur les mêmes appuis, seuls
cas où une telle cohabitation se présente
- Les lignes > 30 000 volts sont visuellement impactantes et des éléments
utiles à l'orientation qui doivent être représentées en tant que telles.
Pour ou contre ?

Je viens de re-lire le paragraphe
https://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/France#Lignes_a.C3.A9riennes
indiquant que power=minor_line pouvait avoir une réalité sur les réseau de
transport d'énergie, notamment lorsqu'ils étaient supportés sur les mêmes
poteaux que les réseaux basse tension.
De mon point de vue, ce n'est jamais le cas.
Le réseau de transport assure le transit de l'électricité entre les grandes
centrales et les bassins de consommation. Il est relayé par la distribution
jusqu'aux consommateurs.

Avec votre accord (ou sans réaction à ce mail), je souhaiterais déplacer le
point line/minor_line dans la partie réseaux de distribution, parce que le
réseau de transport doit être à 100% décrit avec power=line.

Initialement partisan de l'abandon pur et simple de minor_line, je pense au
compromis suivant:
Compte tenu des distances imposées par les tensions auxquelles les lignes
aériennes sont exploitées, minor_line ne saurait être utilisé sur des
lignes > 30 000 volts.
Ce serait évidemment beaucoup mieux, au niveau français, d'établir une
limite ferme à 10 000 volts
Au dessus de cette limite les lignes deviennent visuellement impactantes et
de bons éléments pour s'orienter. C'est donc un débat 100% distribution.
D'autre part, cela permettrait à ceux qui le souhaitent de cartographier
également les lignes basse tension très capillaires sans collisions avec
les réseaux de plus grande importance. On peut avoir de gros soucis quand
le 20 000 volts partage des supports avec la basse tension (ce sont les
seuls cas connus) et ainsi minor_line et line nous permettraient de faire
cohabiter ces éléments.
Visuellement ca colle aussi, et donc cela pourrait contenter ceux qui
affectionnent le rendu.


Au niveau mondial, la discussion n’aboutit pas vraiment, entre ceux qui
souhaitent une description usage/fonction, d'autres pour le rendu. Et les
données sont parfois inextricables pour pas grand chose. Il y a des défis
beaucoup plus structurants en ce moment.
Peut-être parce que c'est un débat local, avoir une situation homogène sur
la France serait déjà un grand pas en avant.


Bonne journée

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


Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

2017-08-30 Per discussione Frédéric Rodrigo

Le 30/08/2017 à 03:49, Francois Gouget a écrit :

Reste à prendre une décision pour les 3631...
J'ai également modifié le code pour ne plus proposé les 3631 sur 
l'intégration des postes.

  * On pourrait le mettre sur une relation regroupant tous les
établissements de la chaîne en question. Mais à ma connaissance il
n'existe pas de relation de ce type ni de recommandation d'en créer.
Il existe par contre un recommandation de ne pas en créer ("relations 
are not collections").



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


Re: [OSM-talk-fr] Création de la liste OSM tagging-fr - communication - fragmentation

2017-08-30 Per discussione marc marc
Le 30. 08. 17 à 10:20, Christian Quest a écrit :
> Le forum est une autre approche complémentaire
je trouve que le forum et la mailing list ont des approches 
complémentaires. tu trouves l'un dépassé, moi je trouve l'inverse
(un email par message, lire/répondre y compris sur smartphone, etc)

Je me demandais dans un précédent email si justement il ne faudrait
pas rapprocher les 2, cad que mailing list et forum ne soient
que 2 interfaces vers la même chose.
chacun choisit son interface préférée en fonction de ses critères.

autre point que j'évoquais : utilité ou non de résumer les longs 
échanges afin que ceux qui veulent zaper les discussions puisse
quand même connaître le résumé
à voir sous quelle forme : email de résumé ou 2-3 lignes dans weeklyOsm
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-it] [Desiderata] HW per servizi

2017-08-30 Per discussione Alessandro Palmas

Il 30/08/2017 09:52, Francesco Pelullo ha scritto:


Un tileserver con grafica personalizzata per l'Italia con simbologia 
da CdS:


- autostrade giallo/verdi e ref esagonale;
- uscite autostradali bianco su sfondo verde
- ref viabilità ordinaria bianco sfondo blu
- etc

Eventualmente, tileserver per mappe escursionistiche con simbologia IGM


Queste però sono visualizzazioni: richiedono sia una certa potenza che 
una discreta banda. Per il momento penso di poter disporre di qualcosa 
che serva per servizi di utilità


Alessandro

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


Re: [Talk-cz] Názvy vodních nádrží a water=reservoir

2017-08-30 Per discussione Michal Poupa
Tech v. n. je tam hodně ale podle mne není problém dát robotem to na Vodní 
nádrž stačí jednoduchý filter

water=reservoir a hledat všechny kombinace skratky v názvu  bez mezer s z 
mezerami a malá velká písmena. Takže nevidím jediný problém proč by robotem 
nešla odstranit zkratka.

 Michal


30. 8. 2017 v 9:46, Pavel Machek :

>> On Wed 2017-08-30 09:25:49, jzvc wrote:
>> Dne 28.8.2017 v 22:23 Michal Poupa napsal(a):
>>> To právě nevím ale většinou to tak v OSM již je...
>>> Ve Waze to tak zadáváme.
>>> 
>>> M.
>>> 
>> 
>> Pokud vim, tak uz je to par patku co se resilo, ze do OSM nepatri zkratky
>> (protoze zkratka se robotem udelat da, ale opacne ne) a v.n. je vyjadreno
>> tagovanim, takze by to tam nemelo byt vubec.
>> 
>> Je to stejny, jako kdyz na tag kostela budes psat ze se to jmenuje kostel
>> Svaty trojice ...
>> 
>> Tim netvrdim ze to na spouste mistech neni, ale nemelo by byt.
> 
> Pozor; ono tohle neni tak jednoduche.
> 
> Kdyz mam
> 
> highway=residential
> name=Milady horakove
> 
> tak nedokazu urcit jestli je to "ulice Milady horakove", "trida..",
> "bulvar..", "namesti..." nebo kdovi co jeste. Taky kostel jeste muze
> byt... ja nevim... "bazilika", "chram", ... Vodni nadrz muze byt
> "prehrada", "vodni dilo"...
> 
> A z tagu nepoznam kterym ze synonym se tomu kostelu rika...
> 
>Pavel
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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


  1   2   >