Re: [OSM-talk-fr] projet du mois : limite de vitesse 80/90 ?

[Jérôme Amagat]

Le lun. 13 août 2018 à 23:10,  a écrit :

> Bonjour les Jérôme et les autres,
> Bon résumé Jérôme Amagat mais une erreur refaite par ton homonyme :
> Le 13/08/2018 à 10:16, Jérôme Seigneuret - jerome.seigneu...@gmail.com a
> écrit :
>
> Comme la notion de séparateurs sur les voies simple n'existe pas vraiment
> hors relation on a un linéaire pour chaque voie séparée ducoup le
> traitement automatique c'est pas vraiment l'idéal et je pense qu'il vaut
> mieux traiter ça sous forme d'alerte pour en faire la vérification ou faire
> un extract overpass pour traiter ces zones
> On peut essayer de coupler ça avec un traitement spatial (voies parallèles
> avec une distance particulière portant le même nom) > donc séparateur
> physique
>
> Et :
> Le 13/08/2018 à 05:35, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
>
> Il y a aussi le problème pour savoir si les chaussés sont considérés comme
> séparées ou pas, vu que si chaussés pas séparées c'est 80 sinon il faut
> regarder les panneaux.
> Pour moi, chaussés séparées = il y a des barrières de sécurité entre les
> chaussés sur une distance "suffisante". il y a des cas ou c'est pas facile
> de juger sur la vue aérienne :(
>
>
> La notion de séparateur n'existe surtout pas dans la loi (on en parlait au
> début).
>

Si ça existe dans la loi, vu que la loi dit : 110 km/h sur les routes à
deux chaussées séparées par un terre-plein central ;
https://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=3489304FCA45A503F10ADE8DBA1C98C6.tplgfr24s_3?cidTexte=LEGITEXT06074228=LEGIARTI37078246=20180814=id#LEGIARTI37078246
Donc si les chaussés sont séparées c'est limité à 110 sauf si un panneau
indique moins!


> Le séparateur, ça peut être une simple ligne continue.
> Si on reprend l'exemple de la D 39 dans le Finistère :
> https://www.openstreetmap.org/edit?editor=id#map=19/48.03703/-4.11814
> (choisir IGN ortho ou regarder sur BBBike
> ),
> le séparateur est un simple trait continu.
> Vérifié pas plus tard qu'hier ;-).
>
> Je comprend pas ton exemple, les chaussés sont pas séparées donc on est
dans le cas :
"3° 80 km/ h sur les autres routes. Toutefois, sur les sections de ces
routes comportant au moins deux voies affectées à un même sens de
circulation, la vitesse maximale est relevée à 90 km/ h sur ces seules
voies. Ces sections font l'objet d'une signalisation routière dans les
conditions prévues par l'article R. 411-25."
Donc 80 dans le sens où il y a une voie et 90 dans le sens où il y a 2
voies.

Des exemples où j'ai du mal à me prononcer :
https://www.openstreetmap.org/way/89353859
https://www.openstreetmap.org/way/293176834
https://www.openstreetmap.org/way/170772903
https://www.openstreetmap.org/way/17044936

Le 13/08/2018 à 10:16, Jérôme Seigneuret - jerome.seigneu...@gmail.com a
> écrit :
>
> j'ai un problème avec le source
> 80, 90, 110 peuvent être du source=FR:rural car FR:rural est du hors agglo
> en fait on ce retrouve sur du FR:rural avec des typicités structurelles:
>  - type 80
>  - type 90
>  - type 110
>
> Non, FR:urban c'est la vitesse par défaut en agglo et c'est 50 et FR:rural
> c'est la vitesse par défaut hors agglo et c'est 80.
> Le reste c'est sous réserve de voiries spécifiques et de panneaux. Tu peux
> aussi ajouter qu'il y a du 130 hors agglo (vitesse par défaut sur
> autoroute). Pourquoi faire un sort différent aux autoroutes ?
>
> 110, 130 ça implique de réserver à certains types de véhicules à moteur,
> donc panneau spécifique obligatoire.
>
> 90, je rappelle le bon message de Jérôme  :
> Le 13/08/2018 à 05:35, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
>
> Toutefois, sur les sections de ces routes comportant au moins deux voies
> affectées à un même sens de circulation, la vitesse maximale est relevée à
> 90 km/ h sur ces seules voies. Ces sections font l'objet d'une
> signalisation routière dans les conditions prévues par l'article R. 411-25.
>
> Donc 90 seulement si panneau l'indiquant, voirie compatible mais pas de
> panneau : on reste à 80.
>

" 80 km/ h sur les autres routes. Toutefois, sur les sections de ces routes
comportant au moins deux voies affectées à un même sens de circulation, la
vitesse maximale est relevée à 90 km/ h sur ces seules voies. Ces sections
font l'objet d'une signalisation routière dans les conditions prévues par
l'article R. 411-25."
Je n'y connais rien en droit.
Mais quand je lis ça, sur une route comportant 2 voies affectées à un même
sens de circulation, qui ne possède pas de panneaux de limitation de
vitesse, je ne comprends pas si celui qui est en faute c'est celui qui
roule à 90 km/h ou si c'est l'autorité qui a oublié de mettre les panneaux!
Le décret aurait pu être plus clair...
en recherchant des site qui en parle j'ai plutot l'impression que les
panneaux ne sont vraiment obligatoire.
par exemple , là :

Re: [OSM-talk-fr] source:maxspeed <> maxspeed:type

[osm . sanspourriel]

Le 14/08/2018 à 00:06, marc marc - marc_marc_...@hotmail.com a écrit :

source: est un préfixe pour la catégorisation des sources.
source:name:br indique par exemple l'origine du name:br.

(complètement inutile sur l'objet)
source vaudra dans ce cas survey ou imagery ou mapillary ou local
knowledge ou opendata ou site avec une licence compatible.
"FR:rural" n'est pas une source, c'est la description du type
du panneau ou de son absence, c'est justement le fondement
du problème avec source:maxspeed

Pas d'accord.
On a abandonné le source parce que sa place est plus sur le changeset.
source:XX indique l'origine du tag XX.
proper translation, ofis publik ar brezhoneg, copied from name sont 
assez similaires au FR:rural.
Et ce n'est pas "survey ou imagery ou mapillary ou local knowledge ou 
opendata", ça c'est bon pour le changeset.

Tu peux bien sûr changer source:name:br en autre chose.

FR:rural est bien une source : dans ce cas la source c'est la 
réglementation.
Que tu ne veuilles pas appeler ça une source ne fait pas que ce n'est 
pas une source.
Si ce n'était pas une source on ne modifierait pas ces données suite au 
passage à 80 km/h !


Et si ce qui te gène c'est que sign et Mappilary sont en conflit c'est 
que tu mélanges deux choses : les sources du changeset (ici Mapillary 
par exemple) et l'origine de la vitesse maximale (la raison d'être).
Et sign ou FR:rural ça me va (mais ne met pas FR:rural pour maxspeed et 
Mapillary en source de changeset ;-)).
Bien sûr on peut pour le plaisir changer la clé afin d'éliminer des 
conflits potentiels. Mais maxspeed:type c'est vraiment pas terrible. 
Alors remplacer un usage répandu partout pour un nom ne voulant pas dire 
grand chose tout en laissant d'autre clés dans le même cas non 
modifiées, bof.
Ou alors tu dis juste zone/sign/default. maxspeed=30 en France avec zone 
serait une limitation par panneau rectangulaire et sign par panneau 
rond. Tu n'as pas besoin de plus. Car comme la vitesse est 30 et que tu 
es en France tu c'est que tu est dans une zone 30 à la française.

Certains défendent cette position :
https://wiki.openstreetmap.org/wiki/Talk:Key:source:maxspeed#maxspeed_zones

N. B. : ici en plus on voit qu'il faudrait en plus dater la vue 
Mapillary pour bien sourcer, certains mettent l'identifiant Mapillary. 
C'est uniquement dans ce cas qu'on aurait un conflit sur 
source:maxspeed, sinon on peut continuer à l'utiliser. Ceci dit on ne 
peut avoir FR:rural et une source mapillary, c'est juste une vue de 
l'esprit sauf panneaux de fin de limitation de vitesse et que tu ne veux 
pas mettre Mapillary en source du changeset.


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

Re: [OSM-talk-fr] source:maxspeed <> maxspeed:type

[marc marc]

Le 13. 08. 18 à 01:02, osm.sanspourr...@spamgourmet.com a écrit :
>>> source:maxspeed
>> il me semblait qu'on était entrain de migrer ces vieux
>> source:maxspeed conflictuel en maxspeed:type
>> j'ai même lancé une discussion pour une édition mécanique à l'échelle
>> de la France qui n'a jusqu'à ce jour pas eu d'opposition
> Alors prem's car je ne vois pas d'intérêt de faire différemment d'ailleurs.
> https://wiki.openstreetmap.org/wiki/Key:source:maxspeed

je ne vais pas refaire toute la discussion précédente mais qlq remarques
https://taginfo.openstreetmap.org/keys/?key=source%3Amaxspeed#map
https://taginfo.openstreetmap.org/keys/?key=maxspeed%3Atype#map
tu constateras l'utilisation aussi un peu partout de maxspeed:type
(même si le source:maxspeed historique reste 5 + utilisé vu son age)
parce que l'utilisation de tag source souffre d'un conflit majeur :
source définit comment tu as obtenu l'information
si t'as vu le panneau, source=survey
les partisans de la veille école des tags sur les objets font
donc des source:maxspeed=survey
tu peux pas en même temps utilisé le même tag pour décrire autre
chose à savoir le type de panneau (ou son absence) comme par ex
source:maxspeed:sign, panneau dont la source peux être survey ou 
mapillary ou imagery (pour les marques au sol) ou opendata...


c'est pour cela que l'opération proposée visait à éliminer ce conflit
en migrant, comme c'est déjà le cas "à la main" de manière non marginale
par de nombreuses personnes les source:maxspeed décrivant le type de 
panneau en maxspeed:type

> De plus en général on évite type qui est un mot valise pour un plus 
> précis (maxspeed:origin par exemple).

oui type c'est pas génial... origin pas bcp mieux.
on peux attendre 10 ans un éventuel avis unanime mondial pour faire
une migration mondiale vers un meilleur mot pour la clef... ou ne pas 
attendre et faire déjà le premier pas d'en finir avec le conflit
de sens pour "source"

> source: est un préfixe pour la catégorisation des sources. 
> source:name:br indique par exemple l'origine du name:br.

(complètement inutile sur l'objet)
source vaudra dans ce cas survey ou imagery ou mapillary ou local 
knowledge ou opendata ou site avec une licence compatible.
"FR:rural" n'est pas une source, c'est la description du type
du panneau ou de son absence, c'est justement le fondement
du problème avec source:maxspeed

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

Re: [OSM-talk-fr] projet du mois : limite de vitesse 80/90 ?

[osm . sanspourriel]

Bonjour les Jérôme et les autres,

Bon résumé Jérôme Amagat mais une erreur refaite par ton homonyme :
Le 13/08/2018 à 10:16, Jérôme Seigneuret - jerome.seigneu...@gmail.com a 
écrit :
Comme la notion de séparateurs sur les voies simple n'existe pas 
vraiment hors relation on a un linéaire pour chaque voie séparée 
ducoup le traitement automatique c'est pas vraiment l'idéal et je 
pense qu'il vaut mieux traiter ça sous forme d'alerte pour en faire la 
vérification ou faire un extract overpass pour traiter ces zones
On peut essayer de coupler ça avec un traitement spatial (voies 
parallèles avec une distance particulière portant le même nom) > donc 
séparateur physique

Et :
Le 13/08/2018 à 05:35, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
Il y a aussi le problème pour savoir si les chaussés sont considérés 
comme séparées ou pas, vu que si chaussés pas séparées c'est 80 sinon 
il faut regarder les panneaux.
Pour moi, chaussés séparées = il y a des barrières de sécurité entre 
les chaussés sur une distance "suffisante". il y a des cas ou c'est 
pas facile de juger sur la vue aérienne :(


La notion de séparateur n'existe surtout pas dans la loi (on en parlait 
au début).

Le séparateur, ça peut être une simple ligne continue.
Si on reprend l'exemple de la D 39 dans le Finistère :
https://www.openstreetmap.org/edit?editor=id#map=19/48.03703/-4.11814
(choisir IGN ortho ou regarder sur BBBike 
), 
le séparateur est un simple trait continu.

Vérifié pas plus tard qu'hier ;-).

Le 13/08/2018 à 10:16, Jérôme Seigneuret - jerome.seigneu...@gmail.com a 
écrit :

j'ai un problème avec le source
80, 90, 110 peuvent être du source=FR:rural car FR:rural est du hors agglo
en fait on ce retrouve sur du FR:rural avec des typicités structurelles:
 - type 80
 - type 90
 - type 110
Non, FR:urban c'est la vitesse par défaut en agglo et c'est 50 et 
FR:rural c'est la vitesse par défaut hors agglo et c'est 80.
Le reste c'est sous réserve de voiries spécifiques et de panneaux. Tu 
peux aussi ajouter qu'il y a du 130 hors agglo (vitesse par défaut sur 
autoroute). Pourquoi faire un sort différent aux autoroutes ?


110, 130 ça implique de réserver à certains types de véhicules à moteur, 
donc panneau spécifique obligatoire.


90, je rappelle le bon message de Jérôme  :
Le 13/08/2018 à 05:35, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
Toutefois, sur les sections de ces routes comportant au moins deux 
voies affectées à un même sens de circulation, la vitesse maximale est 
relevée à 90 km/ h sur ces seules voies. *Ces sections font l'objet 
d'une signalisation routière* dans les conditions prévues par 
l'article R. 411-25.
Donc 90 seulement si panneau l'indiquant, voirie compatible mais pas de 
panneau : on reste à 80.


*Donc je maintiens que FR:rural a un sens et que FR:rural aujourd'hui 
c'est 80.*


Le 13/08/2018 à 05:35, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
Il y a aussi les cas des sorties d'autoroutes ou de trunk en sens 
unique. Sur les autoroute il y a souvent des panneaux 90 au niveau de 
la sortie et il me semble qu'ils n'ont pas bougé, sur les trunk ou 
d'autres routes avec des sorties ressemblant à celle des autoroutes je 
ne sais pas trop, ça doit dépendre des cas...
Oui les sorties de voies express ou encore des voies express perdant 
leur statut à cause d'un débouché ou de virages (cas de la N 165 du côté 
de Daoulas 
).
Là la vitesse est inférieure à la vitesse par défaut, il n'y a en 
général pas de raison de la changer.
Je vais ajouter des sign en source ici. Pour les cas que vous 
rencontrez, je vous conseille de faire pareil.
Normalement assez rapidement on devrait avoir quelqu'un à être passé sur 
les quelques cas litigieux, non ? Normalement on ne fait pas des doubles 
voies sans raison : il doit y avoir du trafic.


Le 13/08/2018 à 05:35, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
Si c'est pas le cas, que le fait qu'il y a 2 voies c'est surtout pour 
doubler alors 90km/h.
Il y a des cas ou c'est compliqué je pense aux cas où 2 routes 
d'importances similaires se rejoignent (ou se séparent) et après (ou 
avant) la route garde 2 voies, une pour chaque route plus longtemps 
que pour une voie d'insertion (ou de sortie)
et le cas où on a 2 voies seulement avant un rond-point sur une 
distance plus ou moins longue.
Avant un rond-point on a souvent un sign 70 voir 50 avant 
 et on n'aura pas un 90 
explicite (accélérer avant un rond-point !). Donc 80 par défaut. Un cas 
de moins.

Reste les deux routes se rejoignant longtemps.
Je n'ai pas de cas sous a main. Comme toi je dirais au cas par cas.

À propos de sign ou FR:rural
Le 13/08/2018 à 05:35, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
ça 

Re: [talk-au] City of Gold Coast / repeat requests of CC BY waivers

[Graeme Fitzpatrick]

On 13 August 2018 at 17:44, Simon Poole  wrote:

> Could naturally be, they didn't give me details, so it is a bit difficult
> to find out what has gone wrong (if anything). I can follow up with them,
> maybe something simply got lost in the mail.
>
> Thanks Simon, that would be good if you can talk to them.

If they've approached LWG, I guess they want more information?

Thanks

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

Re: [Talk-de] Wege des WSV an den Kanälen / tagging

[Christoph Hormann]

On Monday 13 August 2018, Florian Lohoff wrote:
> [...]
>
> Wasserwirtschaft bedeutet hier nämlich nicht Verkehrswege im Sinne
> des "Bundeswasserstraßengesetzes" sondern im Sinne der (Landes)
> "Wasserwirtschaftsgesetze"
>
> Damit geht es um die Erschließung von Wassergewinnungsgebieten und
> nicht die Begleitwege einer Bundeswasserstraße.

Nur zum Verständnis:

Das bedeutet, dass sich die Argumentation für das tagging als 
highway=service auf Wege an Bundeswasserstraßen bezieht und nicht 
notwendigerweise auch auf sonstige Wasserläufe und Kanäle bezieht?

Gewässer-parallele Fahrwege sind ja insgesamt insbesondere auf und am 
Fuße von Hochwasser-Deichen auch bei kleineren Flüssen recht weit 
verbreitet.

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

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

Re: [Talk-cz] geograficke regiony v CR

[Michal Pustějovský]

Souhlasím s Milanem. Je to velká ostuda. A s bodem aspoň odpadne problém 
s přesnou definicí hranice. A když se v budoucnu nějaká data přece jen 
uvolní, není problém bod předělat na relaci.


Michal

Dne 13.08.2018 v 21:32 Milan Cerny napsal(a):

Jen pro zajímavost jsem zadal do hledání v OSM slovo "Šumava" a vypadla na mě 
spousta pekáren Šumava v Liberci a okolí, zastávka autobusu v ČB, kino Šumava, ale o 
pohoří či oblasti ani zmínka.
Stejně tak "Brdy", jen kopec u Kopřivnice.
To mi připadá hodně špatně. Pohledem "z venku", proč používat mapu OSM, když mi 
ani neřekne, kde je Šumava nebo Brdy.

Některá pohoří jsou v OSM jen jako bod zhruba uprostřed oblasti, například 
Pyreneje, Apeniny. Pro tento účel by to mohlo stačit.
https://www.openstreetmap.org/node/3791620621

Milan
  


__

Od: Jan Macura 
Komu: OpenStreetMap Czech Republic 
Datum: 13.08.2018 19:36
Předmět: Re: [Talk-cz] geograficke regiony v CR

2018-08-13 12:29 GMT+02:00 majka :


Troufám si tvrdit, že jde jen o to, koho se zeptat. V daném případě žáka
základní školy
,
případně jeho rodičů.
(...)

Jen netuším, jestli "učí se to ve škole" je povolený zdroj dat ;)


Zajímavá a trefná poznámka :-) source=global_knowledge ? :-)

P.S. Nehci tím nikoho otrávit od mapování, co komu přijde užitečné, jen se
mi zdá, že zrovna v případě geomorf. celků je přidaná hodnota pro uživatele
dat zcela nulová. Těžko totiž zmapovat něco víc, než to, co zkopírujeme z
nějaké jiné mapy, kterou nakreslil nějaký odborník v podstatě od stolu. Na
Wikipedii se např. před nedávnem diskutovalo

rozdílné vymezení geomorf. celků různými autory. Tím se tenhle jev liší
třeba od polí, adres nebo domů, které taky sice importujeme od jinud, ale
celkem snadno jsme schopni je ověřit OTG a případně opravit.

H.


--

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



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




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

Re: [Talk-cz] geograficke regiony v CR

[Milan Cerny]

Jen pro zajímavost jsem zadal do hledání v OSM slovo "Šumava" a vypadla na mě 
spousta pekáren Šumava v Liberci a okolí, zastávka autobusu v ČB, kino Šumava, 
ale o pohoří či oblasti ani zmínka.
Stejně tak "Brdy", jen kopec u Kopřivnice.
To mi připadá hodně špatně. Pohledem "z venku", proč používat mapu OSM, když mi 
ani neřekne, kde je Šumava nebo Brdy.

Některá pohoří jsou v OSM jen jako bod zhruba uprostřed oblasti, například 
Pyreneje, Apeniny. Pro tento účel by to mohlo stačit. 
https://www.openstreetmap.org/node/3791620621

Milan 
 

__
> Od: Jan Macura 
> Komu: OpenStreetMap Czech Republic 
> Datum: 13.08.2018 19:36
> Předmět: Re: [Talk-cz] geograficke regiony v CR
>
>2018-08-13 12:29 GMT+02:00 majka :
>
>> Troufám si tvrdit, že jde jen o to, koho se zeptat. V daném případě žáka
>> základní školy
>> ,
>> případně jeho rodičů.
>> (...)
>>
>> Jen netuším, jestli "učí se to ve škole" je povolený zdroj dat ;)
>>
>
>Zajímavá a trefná poznámka :-) source=global_knowledge ? :-)
>
>P.S. Nehci tím nikoho otrávit od mapování, co komu přijde užitečné, jen se
>mi zdá, že zrovna v případě geomorf. celků je přidaná hodnota pro uživatele
>dat zcela nulová. Těžko totiž zmapovat něco víc, než to, co zkopírujeme z
>nějaké jiné mapy, kterou nakreslil nějaký odborník v podstatě od stolu. Na
>Wikipedii se např. před nedávnem diskutovalo
>
>rozdílné vymezení geomorf. celků různými autory. Tím se tenhle jev liší
>třeba od polí, adres nebo domů, které taky sice importujeme od jinud, ale
>celkem snadno jsme schopni je ověřit OTG a případně opravit.
>
>H.
>
>
>--
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>https://openstreetmap.cz/talkcz
>
>

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

Re: [Talk-GB] Royal Mail trialling 'parcel' post boxes

[SK53]

The photo in the Leicester Mercury and, I think RM publicity, is of this
location

on Abington Street, Northampton. The distinctive name of the chip shop
helped.

Jerry

On 13 August 2018 at 19:16, Philip Barnes  wrote:

> Locations listted in this article
>
> https://www.leicestermercury.co.uk/news/uk-world-news/
> royal-mail-postboxes-take-parcels-1892430
>
> Will get to survey the Elland Road one in the next couple of weeks.
>
> Phil (trigpoint)
>
> On 13/08/2018 13:48, SK53 wrote:
>
> Press release: https://www.royalmail.com/parcel-postboxes
>
> Trial locations are in Leicester & Northampton.
>
> Jerry
>
>
>
> ___
> Talk-GB mailing 
> listTalk-GB@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-gb
>
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Royal Mail trialling 'parcel' post boxes

[Philip Barnes]

Locations listted in this article

https://www.leicestermercury.co.uk/news/uk-world-news/royal-mail-postboxes-take-parcels-1892430

Will get to survey the Elland Road one in the next couple of weeks.

Phil (trigpoint)


On 13/08/2018 13:48, SK53 wrote:

Press release: https://www.royalmail.com/parcel-postboxes

Trial locations are in Leicester & Northampton.

Jerry



___
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] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Daniel Koć]

W dniu 13.08.2018 o 19:23, Frederik Ramm pisze:

> Which code would you then add to a building? 

I guess I was not clear enough.

I meant only the case when there is proper sign on the building, I would
tag it as an address then. Then and only then. It's perfectly verifiable
and I don't have to decide anything.

For the buildings without a plate with OLC number I would not try to tag
it, exactly because it's not clear which number should it be.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[john whelan]

Currently if I wish to send a letter or a package to someone I send it to
John Smith @ 110 main street.

OLC codes replaces 110 main street but it does have limitations but John
smith @ OLC code should get it close enough to be delivered.

The other issue is there are just the odd one or two buildings mapped in
the map that do not match an exact building outline.  I've definitely seen
one tagged with a HOT project tag line.

I suspect  these may be problematic but there again if the OLC code gets us
fairly close it might well be good enough.

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Blake Girardot HOT/OSM]

On Mon, Aug 13, 2018 at 1:23 PM, Frederik Ramm  wrote:
> Hi,
>
> On 08/13/2018 06:46 PM, Daniel Koć wrote:
>>> I also don't see a reason to add the OLC codes in tags in the
>>> database, even if marked on a building.
>
>> Since buildings are not guaranteed to fit into OLC rectangles and they
>> not 1:1 compatible, this usage makes sense for me.
>
> Which code would you then add to a building? Who would be given the
> power to decide (maybe of the several possible codes, one is nicer or
> contains the initials of the owner)? How would it be verifiable which
> code a building has?
>
> Bye
> Frederik


This is all exactly right. I can see a building having any one of
about 4 OLC 10 digit "addresses" on average depending on which imagery
the building was last aligned to.

That is just reality of how we are forever refining our representation
of the real world in a digital format. It has imprecision and this is
the scale where it becomes really obvious, 13m or less.

I am suggesting as a next step, we get a TMS layer that represents
this OLC grid and easily displays the 4, 6, 8, or 10 digit long OLC
for the grind square depending on scale.

Then about 5 of our tools "support" it already  because they support TMS layers.

I deal with these things at large scale and at the individual door
level, we all do who are concerned about this issue, so some tools to
help us visualize at scale and quantity these OLC codes will help a
lot. Plus the easy to solve case of "looking up" an OLC code is
already being added by folks like OSMAnd and OSM if they merge in the
existing pull request. I put in issues with two tools that I would
like to see support them, the HOT Tasking Manager and Fieldpapers.
Having OLC grid layer available in those tools would be very helpful,
especially Fieldpapers. A TMS end point would close the one for the
Tasking Manager.

Searching in OAM by OLC might be nice too, very easy to specify the
place and scale with one code.

As I said below, lets get these OLC codes that are in OSM now out, if
they are even still in there.  Vao, myself and whoever else is
interested in being able to use OLC to some degree in the eco system
of the OSM software community tools will figure out what makes sense
and what people want to do and we will go forward from there :)

I think TMS layer, whomever, however, or plug in for josm as polyglot
said, are all great and would really help the folks who want to work
more with OLC to see what, if any use cases it solves.

Cheers
Blake

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Simon Poole]

Am 13.08.2018 um 18:46 schrieb Daniel Koć:
> W dniu 13.08.2018 o 18:37, Jo pisze:
>
>> I also don't see a reason to add the OLC codes in tags in the
>> database, even if marked on a building.
> Since buildings are not guaranteed to fit into OLC rectangles and they
> not 1:1 compatible, this usage makes sense for me.
>
If you are doing that, why bother with OLC then, when  you can just as
well do some kind of sensible easily digestible house numbering? As you
are recording the value in a geospatial dataset all the advantages of
OLC vanish in a puff of smoke IMHO.



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

Re: [Talk-cz] geograficke regiony v CR

[Jan Macura]

2018-08-13 12:29 GMT+02:00 majka :

> Troufám si tvrdit, že jde jen o to, koho se zeptat. V daném případě žáka
> základní školy
> ,
> případně jeho rodičů.
> (...)
>
> Jen netuším, jestli "učí se to ve škole" je povolený zdroj dat ;)
>

Zajímavá a trefná poznámka :-) source=global_knowledge ? :-)

P.S. Nehci tím nikoho otrávit od mapování, co komu přijde užitečné, jen se
mi zdá, že zrovna v případě geomorf. celků je přidaná hodnota pro uživatele
dat zcela nulová. Těžko totiž zmapovat něco víc, než to, co zkopírujeme z
nějaké jiné mapy, kterou nakreslil nějaký odborník v podstatě od stolu. Na
Wikipedii se např. před nedávnem diskutovalo

rozdílné vymezení geomorf. celků různými autory. Tím se tenhle jev liší
třeba od polí, adres nebo domů, které taky sice importujeme od jinud, ale
celkem snadno jsme schopni je ověřit OTG a případně opravit.

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Oleksiy Muzalyev]

On 13.08.18 19:46, Daniel Koć wrote:

W dniu 13.08.2018 o 18:37, Jo pisze:


I also don't see a reason to add the OLC codes in tags in the
database, even if marked on a building.

Since buildings are not guaranteed to fit into OLC rectangles and they
not 1:1 compatible, this usage makes sense for me.

The OLC could be used also in property titles, for creating a real 
estate market where it could not exist before. Given - the OLC is 
created from coordinates by a mathematical formula and vice versa.


However, the idea was to give an address to 4+ billion people, the 
majority of the planet population, who at the time being do not have any.


Waiting until the houses are numbered and streets are named may take 
quite some time, - just type in google search "slums" and see the images 
tab.


So if it is not allowed to write the OLC as an address, what should 
people write if they do not have house numbers and street names? 
Nothing? Leave it empty as before?


Regions with classic addresses are rather exceptions, the main part of 
humanity does not have them yet at all. And the idea of the OLC is to 
provide an address, not only as a location (coordinates), but also as a 
plaque, legal address, passport record, medical insurance, school 
records, etc.


I can only imagine how humiliating for say a child to say at school that 
he does not have an address.


However, it is too early to worry about a database. I would concentrate 
first on implementing the generation of OLC and a search for OLC at the 
osm.org , i.e. creating an open source standard for an address in 
cooperation with Google Maps and others, similar as browsers agreed on 
HTML, JS, URL, DNS, SSL open standards. And then it will be seen how 
people use it.


Best regards,

O.



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

Re: [Talk-cz] geograficke regiony v CR

[Jan Macura]

Ahoj,

2018-08-13 12:12 GMT+02:00 Petr Vozdecký :

> mohu se mylit, ale proc je dulezite to "on the ground"? Je spousta
> polozek, ktere se nedaji pouhou navstevou mista zjistit, je nutne dalsi
> zjistovani a patrani.
>

protože co nelze v terénu najít, to nemá v {OSM} mapě místo. Sice to nemůžu
najít jako pevné pravidlo na OSM wiki, ale z principů "Map what's on the
ground", "Verifiability" a "Don't map your local legislation, if not bound
to objects in reality" to celkem jasně vyplývá.
Stejně jako nemapujeme hranice volebních okrsků, ačkoliv jsou autoritou
(MVČR) definované, a stejně jako např. nemapujeme prvky ÚSES
,
přestože jsou v územních plánech vymezené.

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Frederik Ramm]

Hi,

On 08/13/2018 06:46 PM, Daniel Koć wrote:
>> I also don't see a reason to add the OLC codes in tags in the
>> database, even if marked on a building.

> Since buildings are not guaranteed to fit into OLC rectangles and they
> not 1:1 compatible, this usage makes sense for me.

Which code would you then add to a building? Who would be given the
power to decide (maybe of the several possible codes, one is nicer or
contains the initials of the owner)? How would it be verifiable which
code a building has?

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] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Daniel Koć]

W dniu 13.08.2018 o 18:37, Jo pisze:

> I also don't see a reason to add the OLC codes in tags in the
> database, even if marked on a building.

Since buildings are not guaranteed to fit into OLC rectangles and they
not 1:1 compatible, this usage makes sense for me.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Jo]

I would think that if you are in the field, apps like OsmAnd and Maps.ME
can show you the OLC address of where you are.

If you want to see a grid in JOSM or iD, it should be trivial to either
show them as transparent imagery, or in the case of JOSM, have a plugin
draw the grid and show it as an extra layer you can toggle on or off.

I also don't see a reason to add the OLC codes in tags in the database,
even if marked on a building.

If I paint the coordinates of my house on it, are you going to map that
too? And if so, would you add them to lon and lat tags or to addr:housename?

Polyglot

Op ma 13 aug. 2018 om 18:23 schreef Blake Girardot HOT/OSM <
blake.girar...@hotosm.org>:

> Hi Tom,
>
> This is an example of the first way I and I think others in the
> humanitarian world need to use OLCs to evaluate them for what they can
> or can not solve for humanitarian and other use cases:
>
> https://twitter.com/BlakeGirardot/status/1028689726088388609
>
> We need to deal with them at scale, not at the "look up" an individual
> address process which is trivial to solve.
>
> That is really the first step, for folks to learn the grid and it's
> inherent scale steps and how that translates into OLC codes of various
> lengths.
>
> Cheers,
> blake
>
>
>
> On Mon, Aug 13, 2018 at 11:23 AM, Tom Lee  wrote:
> > I'm surprised to see that this conversation has made it past the weekend.
> > Since it has, let me add my voice to those suggesting that encoding OLC
> in
> > the database (or any other values that can be algorithmically derived
> from
> > geometry) makes very little sense. I'm grateful to everyone who has
> already
> > made this point, in various ways and with various levels of forcefulness.
> >
> > If the folks advocating for OLC would like to walk through the rationale
> > some more or explore alternative ways of getting OLC into their
> workflow, I
> > suspect that a number of people on this thread would be happy to talk
> > through it, myself included. Please don't hesitate to email.
> >
> > Tom
> >
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >
>
>
>
> --
> 
> Blake Girardot
> Humanitarian OpenStreetMap Team
>
> ___
> 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-us] State Open Data

[Kevin Kenny]

On Sun, Aug 12, 2018 at 4:28 PM Kevin Kenny  wrote:
> > TL:DR: The closest answer to Clifford Snow's original question for New
> > York is http://gis.ny.gov/gisdata/inventories/details.cfm?DSID=932
> > which is virtually certain (the law, as always is muddy) to be
> > ODBL-compatible (and in fact, there is a colourable case that it is in
> > the Public Domain.) The digital raster quads available from
> > https://gis.ny.gov/gisdata/quads/ (these are State, not USGS!) are
> > also a potential data source for tracing, and again, aren't deeply
> > mired in the legal swamp.

I did some spot checks on the file cited above, and it's better than I
remembered. Comparing it with some of the places that I've been
meaning to return to and field-survey, it's much freer from
hallucination than TIGER. It's a bit out of date (which means both
that new development is missing and that a few abandoned roads are
there), but it's not horrible (while the TIGER-derived data are indeed
horrible).

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Blake Girardot HOT/OSM]

Hi Tom,

This is an example of the first way I and I think others in the
humanitarian world need to use OLCs to evaluate them for what they can
or can not solve for humanitarian and other use cases:

https://twitter.com/BlakeGirardot/status/1028689726088388609

We need to deal with them at scale, not at the "look up" an individual
address process which is trivial to solve.

That is really the first step, for folks to learn the grid and it's
inherent scale steps and how that translates into OLC codes of various
lengths.

Cheers,
blake



On Mon, Aug 13, 2018 at 11:23 AM, Tom Lee  wrote:
> I'm surprised to see that this conversation has made it past the weekend.
> Since it has, let me add my voice to those suggesting that encoding OLC in
> the database (or any other values that can be algorithmically derived from
> geometry) makes very little sense. I'm grateful to everyone who has already
> made this point, in various ways and with various levels of forcefulness.
>
> If the folks advocating for OLC would like to walk through the rationale
> some more or explore alternative ways of getting OLC into their workflow, I
> suspect that a number of people on this thread would be happy to talk
> through it, myself included. Please don't hesitate to email.
>
> Tom
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>



-- 

Blake Girardot
Humanitarian OpenStreetMap Team

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

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Rasťo Šrámek]

Perhaps let me add my 2c:
In my mental model there are two cases in which plus codes attain different
semantics: a plus code as an encoding of latitude and longitude,
and a plus code written on an sign above a door or on a house. If you asked
me I'd say the first should not be ingested into a database and the
second is not really different than any other street number if the database
aims to reflect the ground truth.

On Mon, Aug 13, 2018 at 5:23 PM, Tom Lee  wrote:

> I'm surprised to see that this conversation has made it past the weekend.
> Since it has, let me add my voice to those suggesting that encoding OLC in
> the database (or any other values that can be algorithmically derived from
> geometry) makes very little sense. I'm grateful to everyone who has already
> made this point, in various ways and with various levels of forcefulness.
>
> If the folks advocating for OLC would like to walk through the rationale
> some more or explore alternative ways of getting OLC into their workflow, I
> suspect that a number of people on this thread would be happy to talk
> through it, myself included. Please don't hesitate to email.
>
> Tom
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Tom Lee]

I'm surprised to see that this conversation has made it past the weekend.
Since it has, let me add my voice to those suggesting that encoding OLC in
the database (or any other values that can be algorithmically derived from
geometry) makes very little sense. I'm grateful to everyone who has already
made this point, in various ways and with various levels of forcefulness.

If the folks advocating for OLC would like to walk through the rationale
some more or explore alternative ways of getting OLC into their workflow, I
suspect that a number of people on this thread would be happy to talk
through it, myself included. Please don't hesitate to email.

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

Re: [talk-au] City of Gold Coast / repeat requests of CC BY waivers

[Andrew Harvey]

There's a number of people here in Australia who are keen to use our
governments data to improve OSM and I'm sure there's been a lot of double
ups in requests. I'd encourage everyone who's identifying data sources and
asking for permissions or waivers to contribute to
https://wiki.openstreetmap.org/wiki/Australian_Data_Catalogue as a form of
documentation.

I did also send and email about the waiver to opend...@goldcoast.qld.gov.au
but I never received a response. I think it makes sense to send one or two
follow up emails spaced out, as most of the time the emails might get lost,
forgotten, and sometimes after a few follow ups we get the waiver back.

On 13 August 2018 at 17:07, Simon Poole  wrote:

> We've (as in the LWG) have received a mail from the City of Gold Coast
> concerning multiple repeat requests for CC BY waiver (no need to point out
> that that can be annoying). IMHO the AUS community already documents what
> is going on rather well https://wiki.openstreetmap.
> org/wiki/Australian_Data_Catalogue so this may simply be a one off
> incident.
> So in any case, could you all try to avoid this happening as far as
> possible? While I don't quite see a Newbie sending such a request maybe it
> would be a good idea to send welcome mails and point to the list if that
> isn't already happening now (simplest way to do that is to get a new mapper
> RSS feed from Pascal Neis https://resultmaps.neis-one.
> org/newestosm?c=Australia#4/-29.68/133.30).
>
> Thanks
>
> Simon
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-se] Bulk Download of precise tiles

[Pierre Mesure]

Salut Lonni,


Je n'ai pas la réponse à ta question mais je souhaitais simplement te
souhaiter la bienvenue en Suède (avec un peu de retard). Je suis à
Stockholm, n'hésite pas à demander si tu passes visiter et que tu cherches
un hébergement, j'habite dans une grosse coloc et on a de la place.


Bonne fin d'été !


Pierre


Le 13 août 2018 à 15:23:21, Lonni Besançon (lonni.besan...@gmail.com) a
écrit:

Hello everyone. I am new to the mailing list and decided to contact you
after the suggesting was made by people from OSM.

Here is the reason why I am contacting you today.

I would love to render a visualization of some data on Stockholm that needs
to be put on a map with precize positioning. For security reasons, the
machine that stores the data doesn't have access to the internet and I
would therefore like to download precise tiles for Stockholm (highest zoom
levels). I guess I don’t need to have a world map first, so it would only
be tiles for the Stockholm area. I know this is discouraged by OSM Tile
Usage Policy and I therefore wanted to talk about it here. Would it be
possible for this one time to make it possible for me to bulk download
tiles ?

Thank you in advance for your time, and I look forward to the discussions
we are going to have.

Best,

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

Re: [OSM-talk-fr] projet du mois : limite de vitesse 80/90 ?

[Rpnpif]

Bonjour,

Personnellement, je n'ajoute plus désormais le FR:rural car il n'a
plus de sens parce qu'il est applicable en urbain. FR:implicite me
semblerait préférable. 

Par ailleurs, il faut vérifier la date de la modification quand on a
maxspeed=90 pour ne pas enlever une correction faite après le 1er
juillet.

En définitive, il faut connaître le terrain. Et je suis d'accord avec
ce qu'a écrit Marc Marc.

-- 
Alain Rpnpif

Le 13 août 2018, Jérôme Seigneuret a écrit :

> Bonjour,
> Sauf que pour les 80 ou 90 ou 110 en soit il n'y a pas l'obligation d'avoir
> un panneau.
> 
> Le code de la route dit
> 130 km/h sur les autoroutes ;
> 110 km/h sur les routes à deux chaussées séparées par un terre-plein
> central ;
> 90 km/h sur les autres routes.
> et maintenant on décompose le 90
> 
> 90 sur les routes à double sens de circulation opposé avec un terre-plein
> central
> 80 sur les routes n'ayant pas de séparateur et à double sens de circulation,
> 90 pour les doubles voies dans le même sens de circulation sans séparateur
> 
> Ducoup ce tableau dans le wiki est incomplet
> FR:motorway 130 /110 (raining)
> FR:rural 80
> FR:urban 50
> 
> Le FR:rural est faux car c'est omettre des cas
> 
> On est sur un FR:rural80 et FR:rural90 et FR:trunk (FR:rural110) si l'on
> considère une double voies avec séparateur à terre-plein central
> 
> Les valeurs ci-dessus sont implicites et ne nécessitent pas de panneaux
> sauf à vouloir faire un rappel aux gens ayant du mal avec le code de la
> route d'ailleurs j'ai essayé de voir le contenu du code et de la convention
> de vienne et j'ai pas vu d'obligation de signalisation horizontale ou
> verticale.
> 
> j'ai un problème avec le source
> 80, 90, 110 peuvent être du source=FR:rural car FR:rural est du hors agglo
> en fait on ce retrouve sur du FR:rural avec des typicités structurelles:
>  - type 80
>  - type 90
>  - type 110
> 
> 
> Une route à simple voie peut aussi être élevé à 110 si le dépassement le
> permet (à mon avis ça doit vraiment être rare en France) je connais une 3
> voie 110 avec une voie au centre permettant le dépassement pour les deux
> cotés de circulation (je passe pas mon temps sur la route donc vous avez
> surement d'autres exemples)
> 
> Ducoup c'est comme en ville, si l'on doit passer à 70 ou à 30, on est
> obligé d'informer physiquement avec des panneaux supplémentaires avec
> rappel à chaque intersection sinon on revient à la vitesse par défaut
> (sauf cas particulier des panneau carré mentionnant des zones 30 et 20)
> Cela entraîne beaucoup de cas avec des forward backward car les communes et
> services départementaux omettent souvent cette notion
> De même sur route hors agglo avec du 70 ou 110 (et maintenant 90 si il le
> veulent)
> et sur autoroute 90 110  (70 ??? périphérique autoroutier)
> 
> on peux être sur une route de type 110 et avoir un maxspeed=90 avec un
> source:maxspeed=sign
> 
> Dans tous les cas où un panneau est apparu c'est ducoup explicit et ça
> impose aux DDE de faire une mise à jour des panneaux.
> Dans ce cas source:maxspeed=sign pour moi c'est ok
> 
> Comme la notion de séparateurs sur les voies simple n'existe pas vraiment
> hors relation on a un linéaire pour chaque voie séparée ducoup le
> traitement automatique c'est pas vraiment l'idéal et je pense qu'il vaut
> mieux traiter ça sous forme d'alerte pour en faire la vérification ou faire
> un extract overpass pour traiter ces zones
> On peut essayer de coupler ça avec un traitement spatial (voies parallèles
> avec une distance particulière portant le même nom) > donc séparateur
> physique
> 
> Ajouter source:maxspeed:date pour savoir si ça a été renseigné avant
> 2018-07 ou après me semble utile
> 
> Bonne journée
> 
> 
> 
> Le lun. 13 août 2018 à 05:36, Jérôme Amagat  a
> écrit :
> 
> > D’après taginfo :
> > Le 11 juillet :
> > 90  95 044
> > 80  10 967
> >
> > le  21 juillet :
> > 90 91461
> > 80 15126
> >
> > le 13 août :
> > 90 83452
> > 80 25193
> >
> > ça augmente mais pas très très vite :)
> >
> > La région Auvergne Rhône Alpes est à jour (sauf quelques cas où c'est pas
> > simple avec seulement la vue aérienne)
> >
> > rappel du décret qui change la loi :
> > https://www.legifrance.gouv.fr/eli/decret/2018/6/15/INTS1800012D/jo/texte
> > en gros, il y a ça d'important :
> > « 3° 80 km/ h sur les autres routes. Toutefois, sur les sections de ces
> > routes comportant au moins deux voies affectées à un même sens de
> > circulation, la vitesse maximale est relevée à 90 km/ h sur ces seules
> > voies. Ces sections font l'objet d'une signalisation routière dans les
> > conditions prévues par l'article R. 411-25. »
> > (le reste du décret c'est : 80 par temps de pluie donc pareil qu'avant,
> > les bus doivent aussi respecter les nouvelles limitations à 80 et les
> > autorités doivent communiquer la liste des sections où la limite reste à 90
> > parce qu'il y a 2 voies dans le même sens (ça serai bien qu'il la
> > communique aussi en open data!))
> >

[Talk-se] Bulk Download of precise tiles

[Lonni Besançon]

Hello everyone. I am new to the mailing list and decided to contact you after 
the suggesting was made by people from OSM.

Here is the reason why I am contacting you today.

I would love to render a visualization of some data on Stockholm that needs to 
be put on a map with precize positioning. For security reasons, the machine 
that stores the data doesn't have access to the internet and I would therefore 
like to download precise tiles for Stockholm (highest zoom levels). I guess I 
don’t need to have a world map first, so it would only be tiles for the 
Stockholm area. I know this is discouraged by OSM Tile Usage Policy and I 
therefore wanted to talk about it here. Would it be possible for this one time 
to make it possible for me to bulk download tiles ?

Thank you in advance for your time, and I look forward to the discussions we 
are going to have.

Best,

Lonni___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-GB] Royal Mail trialling 'parcel' post boxes

[Jez Nicholson]

Yeah sorry, Royal Mail don't like anyone knowing where post boxes are ;)

On Mon, 13 Aug 2018 at 14:01 Philip Barnes  wrote:

> Interesting, but cannot see any locations to use as survey hints. Although
> I can guess at one or two in Leicester.
>
> Phil (trigpoint)
>
> On 13 August 2018 13:48:51 BST, SK53  wrote:
>>
>> Press release: https://www.royalmail.com/parcel-postboxes
>>
>> Trial locations are in Leicester & Northampton.
>>
>> Jerry
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Royal Mail trialling 'parcel' post boxes

[Dave F]

I wonder if, like South West ambulances with defibrillators, they 
believe the public knowing their locations is a security risk.


DaveF

On 13/08/2018 14:00, Philip Barnes wrote:
Interesting, but cannot see any locations to use as survey hints. 
Although I can guess at one or two in Leicester.


Phil (trigpoint)

On 13 August 2018 13:48:51 BST, SK53  wrote:

Press release: https://www.royalmail.com/parcel-postboxes

Trial locations are in Leicester & Northampton.

Jerry


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


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


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

Re: [Talk-de] Wege des WSV an den Kanälen / tagging

[Florian Lohoff]

On Sun, Aug 12, 2018 at 06:34:15PM +0200, Martin Koppenhoefer wrote:
> Mal ketzerisch gefragt, brauchen wir dann service überhaupt noch? Bei
> Zufahrten zu anderen technischen Anlagen wie Häfen, Staudämmen,
> Brunnen und Transformatoren, etc. könnte man immer sagen, die Wege
> dienten der “Bewirtschaftung”.  Geht es nicht gerade darum, _was_
> bewirtschaftet wird? Sind die Kanäle eher Wäldern oder eher Feldern
> und Wiesen gleichzusetzen, oder sind alle Wege zur Bewirtschaftung
> tracks?

Einer geht noch - Die WSV macht ganz deutlich das es sich bei dem
Kanalbegeleitenden Weg um ein Betriebsgelände des WSV handelt. Der
Weg ist teil der Bundeswasserstraße und gehört dem Bund und dient
der Unterhaltung der Wasserstraße. Ein Begehen und Befahren mit dem
Fahrrad ist geduldet.

Die Begleitwege unterliegen nicht dem normalen Straßen und Wegerecht der
Bundesländer.

http://www.rs1.ruhr/fileadmin/user_upload/RS1/pdf/RS1_Machbarkeitsstudie_web.pdf

Radverkehr ist für die Wasser- und Schifffahrts­verwaltung
des Bundes ein vertrautes Handlungsfeld; bei der Nut-
zung der Betriebswege an Bundeswasserstraßen auch
als Radweg bleiben die Betriebswege Teil der Bundes-
wasserstraße und sind im Eigentum des Bundes. Die
Benutzung durch Radfahrerinnen und Radfahrer sowie
Fußgängerinnen und Fußgänger wird in Bereichen, in
denen der Zustand dies ermöglicht, auf eigene Gefahr
geduldet. Notwendig wird eine Übertragung der Verkehrs-
sicherungspflicht auf die Kommunen über einen Gestat-
tungsvertrag. Die annähernd ausschließliche Nutzung als
Rad(schnell)weg, neben der Funktion als Betriebsweg, ist
aufgrund vielfacher Nutzung als Naturraum und Naherho-
lungsgebiet nicht zu realisieren. Bei der Umsetzung eines
Radschnellwegs nach den Qualitätskriterien des Landes
ergibt sich eine Vielzahl von neuen Herausforderungen.

[ ... ]

Die vorrangige
Zweckbestimmung ist in jedem Fall die der Bundes-
wasserstraßen. Der WSV ist auf ihren Wegen bisher
keine doppelte oder nachrangige Widmung bekannt.
Von Seiten der WSV wurde dargestellt, dass alle
relevanten Regelungstatbestände einschließlich
der Verkehrssicherungspflicht durch einen privat­
rechtlichen Gestattungsvertrag abgedeckt werden
können. Darüber hinaus unterliegt der Betriebsweg
als Zubehör zur Bundeswasserstraße der wegerecht­
lichen Widmung der Wasserstraße und teilt als un-
trennbarer Bereich der Wasserstraße ihr rechtliches
Schicksal. Eine zusätzliche Widmung des Betriebs-
weges nach dem Straßen- und Wegerecht NRW sei
daher nicht zulässig. Die Möglichkeit einer doppelten
(nachrangigen) Widmung sollte daher im Dialog mit
dem BMVI und dem MBWSV geprüft werden.

[ ... ]

• Sowohl durch das Kommunikationskonzept als auch
durch die Gestaltung ist deutlich zu machen, dass
sich die Nutzerinnen und Nutzer auf einem Betriebs-
gelände befinden, auf dem mit plötzlichen Hindernis-
sen und Unterhaltungsarbeiten zu rechnen ist. Hierzu
gehört auch eine zurückhaltende Beschilderung und
Signalisierung.

http://www.wsa-duisburg-meiderich.wsv.de/service/Images/WaStrBAV8701352391673909407.pdf

§ 2 Benutzungsverbot
  1) Es ist verboten die bundeseigenen Schifffahrts - und Betriebsanlagen, 
insbesondere Schleusen, 
  Schiffshebewerke, Wehre, Schutzhäfen, Bauhäfen, Bauhöfe, Schirrhöfe, 
Schiffhöfe sowie Werkstätten, 
  Pegelanlagen, Sicherheitstore, Sperrwerke, Dämme, Buhnen und Parallelwerke 
außerhalb ihrer 
  Zweckbestimmung, insbesondere durch Betreten, Befahren, Abstellen von 
Fahrzeugen aller Art, Zelten, 
  Viehtreiben, Reiten oder durch Umgang mit Feuer; bundeseigene Ufergrundstücke 
und Betriebswege 
  außerhalb ihrer Zweckbestimmung, insbesondere durch Befahren mit 
Kraftfahrzeugen einschließlich 
  Krafträdern, Kleinkrafträdern und Mobilitätshilfen, durch Abstellen von 
Fahrzeugen aller Art, Zelten, 
  Viehtreiben, Reiten oder durch Entzünden von Feuer zu benutzen 
(Benutzungsverbot). Ausgenommen 
  von dem Benutzungsverbot sind das Betreten der bundeseigenen Ufergrundstücke 
und Betriebswege 
  durch Fußgänger und das Befahren der Betriebswege mit Fahrrädern. Handlungen 
im Sinne des Satzes 2 
  geschehen jeweils auf eigene Gefahr
  
-- 
Florian Lohoff f...@zz.de
 UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Talk-GB] Royal Mail trialling 'parcel' post boxes

[Philip Barnes]

Interesting, but cannot see any locations to use as survey hints. Although I 
can guess at one or two in Leicester.

Phil (trigpoint) 

On 13 August 2018 13:48:51 BST, SK53  wrote:
>Press release: https://www.royalmail.com/parcel-postboxes
>
>Trial locations are in Leicester & Northampton.
>
>Jerry

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Fwd: 2 Great Lakes missing

[Christoph Hormann]

On Monday 13 August 2018, SelfishSeahorse wrote:
>
> Thanks for the tip; I din't think of it. Actually my computer had
> more difficulties to calculate that i had to find the errors. :-)

Note checking this kind of errors on large multipolygons is not really 
that difficult.  For each of the big lakes that is a few dozen MB of 
download via overpass API and then a few seconds with osmium to 
assemble the multipolygon.  You can easily set this up to run on a 
daily basis to check a few lakes you want to keep an eye on.

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

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

[Talk-GB] Royal Mail trialling 'parcel' post boxes

[SK53]

Press release: https://www.royalmail.com/parcel-postboxes

Trial locations are in Leicester & Northampton.

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

Re: [Talk-cz] nenalezené spojení

[petr . kadlec]

Ahoj,

On Mon, Aug 13, 2018 at 8:04 AM  wrote:

> Zkoušel jsem to tedy na stránkách www.openstreetmap.org a tam jsem dopadl
> stejně (někdy to spojení vyhledá a někdy ne).
>
>
> https://www.openstreetmap.org/directions?engine=osrm_car=50.3539%2C14.7865%3B50.1066%2C14.2694
>

Mě to funguje v zásadě dobře, jenom to API vrací občas 429 Too Many
Requests, takže je potřeba chvíli počkat a zkusit to znovu. Ale nemyslím,
že by to souviselo s konkrétními místy, jen s voláním toho API.

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

Re: [Talk-de] Wege des WSV an den Kanälen / tagging

[Florian Lohoff]

On Mon, Aug 13, 2018 at 02:18:23PM +0200, Florian Lohoff wrote:
> > "Als Wirtschaftswege werden in Deutschland Wege wie Feld-, Wald- oder
> > *Wasserwirtschaftswege* bezeichnet".

Und bitte mach dir die Mühe mal das BGH Urteil zu lesen - Von "Wasser"
ist in dem ganzen Urteil keine Rede. Kommt nicht einmal drin vor.
Das hat sich also jemand weil es ihm in den Kram passt aus den Fingern
gesogen.

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


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

Re: [Talk-de] Wege des WSV an den Kanälen / tagging

[Florian Lohoff]

On Sun, Aug 12, 2018 at 06:34:15PM +0200, Martin Koppenhoefer wrote:
> sent from a phone
> 
> > On 12. Aug 2018, at 18:12, chris66  wrote:
> > 
> > Ja, das ist meine Meinung.
> > 
> > Es handelt sich um Privatwege die der Bewirtschaftung der Kanäle dienen.
> > Fußgänger und Radfahrer sind auf eigene Gefahr erlaubt.
> > 
> > typisches Tagging:
> > 
> > highway=track
> 
> Mal ketzerisch gefragt, brauchen wir dann service überhaupt noch? Bei
> Zufahrten zu anderen technischen Anlagen wie Häfen, Staudämmen,
> Brunnen und Transformatoren, etc. könnte man immer sagen, die Wege
> dienten der “Bewirtschaftung”.  Geht es nicht gerade darum, _was_
> bewirtschaftet wird? Sind die Kanäle eher Wäldern oder eher Feldern
> und Wiesen gleichzusetzen, oder sind alle Wege zur Bewirtschaftung
> tracks?
> 
> Das deutsche Wiki ist hierzu zwar eindeutig, indem es zu tracks nur
> diejenigen Wirtschaftswege zählt, die “ hauptsächlich für die Land-
> oder Forstwirtschaft genutzt” werden, aber das ist vielleicht auch nur
> Zufall.

Hier wird alles zu einem "Wirtschaftsweg" gemacht was irgendwas
bewirtschaftet und das ist IMHO im ursprünglichen Sinne des Tracks völliger
Mumpitz. Als Landbewohner ärgert es mich massiv das für die
Stadtbewohner hinter dem Ortsschild alles nur noch Track ist. Das ist
für mich völliger Unsinn.

Für mich ist die Authorität das hier:

https://wiki.openstreetmap.org/wiki/Tag:highway=track

Und da geht ganz klar draus hervor das es sich im engeren Sinne um
überwiegend Land und Forstwirtschaftlich genutzte Wege geht.

Sobald da ein Schulbus fährt, die Müllabfuhr, Der Postbote dann kann
das in diesem Sinne kein Track sein. Denn selbst wenn die Müllabfuhr nur
25 mal im Jahr kommt ist das mehr Verkehr als alle Landmaschinen
zusammen.

Und die Begleitwege entlang der Kanäle sind keine Land oder
Forstwirtschaftlichen Wege (Auch keine Wasserwirtschaftlichen).
Das dient der Kontrolle und Unterhaltung einer Bundeswasserstraße.

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


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

Re: [OSM-talk-fr] projet du mois : limite de vitesse 80/90 ?

[Philippe Verdy]

La cause probable est que la route était découpée mais a été refusionnée :
les valeurs ont été fusionnées séparées par des point-virgules. Cela
signale une anomalie où la fusion n'aurait pas du avoir lieu.

Le lun. 13 août 2018 à 13:34, David Crochet  a
écrit :

> Bonjour
>
>
> Le 13/08/2018 à 13:23, Julien Lepiller a écrit :
> > donne une vitesse limite de « 30;50 ». C'est 30 ou 50 ? Qu'est-ce que
> > ça veut dire ?
>
> Quand tu regardes ce que tu peux voir, mais ce que tu ne peux pas
> utiliser, c'est qu'il y a un ralentisseur, donc un passage à 30
>
> le chemin devrait être découpé en plusieurs morceaux afin d'y placer les
> bonnes limitations de vitesses dur les bonnes sections
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Wege des WSV an den Kanälen / tagging

[Florian Lohoff]

On Sun, Aug 12, 2018 at 06:15:51PM +0200, chris66 wrote:
> Am 09.08.2018 um 09:57 schrieb Christoph Hormann:
> 
> > Bei highway=track ist die land- und forstwirtschaftliche Nutzung
> > übrigens keine abschließende Aufzählung von möglichen Nutzungen, im
> > Englischen steht da ein 'etc.' dran.  Hier kann man die
> > wasserwirtschaftliche Nutzung in Analogie durchaus mit einbeziehen,
> > denn da sind ja erhebliche Ähnlichkeiten.  Wie der Feldweg primär zum
> > generellen Zugang zu den angrenzenden Feldern dient, dient der
> > wasserwirtschaftliche Weg zum Zugang zum angrenzenden Gewässer in der
> > Strecke.
> 
> Jepp, siehe auch:
> 
> https://de.wikipedia.org/wiki/Wirtschaftsweg
> 
> "Als Wirtschaftswege werden in Deutschland Wege wie Feld-, Wald- oder
> *Wasserwirtschaftswege* bezeichnet".

Wir lesen den Absatz zuende:

---Y
Als Wirtschaftswege werden in Deutschland Wege wie Feld-, Wald- oder
Wasserwirtschaftswege bezeichnet. Nach einem Urteil des
Bundesgerichtshofes vom 18. November 1975[1] spricht man von Feld-,
Wald-, Wiesen-, Weinbergs- und sonstigen Wirtschaftswegen unabhängig von
der Wegbefestigung, wenn sie

* überwiegend land- oder forstwirtschaftlichen Zwecken dienen und
* keine überörtliche Bedeutung haben
---Y

Wasserwirtschaft bedeutet hier nämlich nicht Verkehrswege im Sinne
des "Bundeswasserstraßengesetzes" sondern im Sinne der (Landes)
"Wasserwirtschaftsgesetze"

Damit geht es um die Erschließung von Wassergewinnungsgebieten und nicht
die Begleitwege einer Bundeswasserstraße.

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


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

Re: [OSM-talk] Fwd: 2 Great Lakes missing

[James]

Yeah those great "lakes" are such a massive relations... I think I can make
toast on my computer while it's calculating the errors. Thanks for fixing
it Selfish Seahorse

On Mon., Aug. 13, 2018, 9:12 a.m. SelfishSeahorse, <
selfishseaho...@gmail.com> wrote:

> On Mon, 13 Aug 2018 at 14:01, Christoph Hormann  wrote:
> >
> >
> > Note you can easily check if there are broken multipolygons in the OSM
> > inspector:
> >
> >
> http://tools.geofabrik.de/osmi/?view=areas=-84.14378=46.10509=8
> >
> > If a lake multipolygon is broken the lake outline will be shown as
> > context there and the location of the error usually in red (self
> > interaection) or magenta (ring not closed).
>
> Thanks for the tip; I din't think of it. Actually my computer had more
> difficulties to calculate that i had to find the errors. :-)
>
> Regards
> Markus
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: 2 Great Lakes missing

[SelfishSeahorse]

On Mon, 13 Aug 2018 at 14:01, Christoph Hormann  wrote:
>
>
> Note you can easily check if there are broken multipolygons in the OSM
> inspector:
>
> http://tools.geofabrik.de/osmi/?view=areas=-84.14378=46.10509=8
>
> If a lake multipolygon is broken the lake outline will be shown as
> context there and the location of the error usually in red (self
> interaection) or magenta (ring not closed).

Thanks for the tip; I din't think of it. Actually my computer had more
difficulties to calculate that i had to find the errors. :-)

Regards
Markus

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

Re: [OSM-talk] Fwd: 2 Great Lakes missing

[SelfishSeahorse]

Hi!

On Mon, 13 Aug 2018 at 13:50, Tom Hughes  wrote:
>
> You should see the changes at z13+ but z0-12 are only rendered once a
> month or when the style changes.

Thanks for your explanation. This also explains why it was not noticed
that the lakes had disappeared until about a month after the faulty
edits at Lake Huron.

Regards
Markus

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

Re: [OSM-talk] Fwd: 2 Great Lakes missing

[Christoph Hormann]

Note you can easily check if there are broken multipolygons in the OSM 
inspector:

http://tools.geofabrik.de/osmi/?view=areas=-84.14378=46.10509=8

If a lake multipolygon is broken the lake outline will be shown as 
context there and the location of the error usually in red (self 
interaection) or magenta (ring not closed).

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

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

Re: [OSM-talk] Fwd: 2 Great Lakes missing

[Tom Hughes]

You should see the changes at z13+ but z0-12 are only rendered once a
month or when the style changes.

Tom

On 13/08/18 12:36, SelfishSeahorse wrote:

Apparently I sent the message only to James ... So here it is for the
rest of you. eanwhile the lakes are rendered):

-- Forwarded message -

Hi

There were quite a few problems with these multipolygons (overlapping
and unclosed ways, no role, inner ways belonging to wrong
multipolygon), which i've just fixed:




The multipolygons should be okay now – at least JOSM and i couldn't
find any more problems. :-) However they still don't render ... Could
it be that this is has to do with these server issues:

?

Regards

Markus

On Fri, 10 Aug 2018 at 02:25, James  wrote:


someone probably broke them again... happens quite often sadly...

On Thu., Aug. 9, 2018, 9:05 p.m. Daniel Koć,  wrote:


Hi,

Is anybody aware what happened to Lake Superior and Lake Huron?

https://www.openstreetmap.org/relation/4039486

https://www.openstreetmap.org/relation/1205151


They were changed 20 and 3 days ago, respectively, and they stopped
being rendered both on default and on humanitarian map.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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




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

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

[OSM-talk] Fwd: 2 Great Lakes missing

[SelfishSeahorse]

Apparently I sent the message only to James ... So here it is for the
rest of you. eanwhile the lakes are rendered):

-- Forwarded message -

Hi

There were quite a few problems with these multipolygons (overlapping
and unclosed ways, no role, inner ways belonging to wrong
multipolygon), which i've just fixed:




The multipolygons should be okay now – at least JOSM and i couldn't
find any more problems. :-) However they still don't render ... Could
it be that this is has to do with these server issues:

?

Regards

Markus

On Fri, 10 Aug 2018 at 02:25, James  wrote:
>
> someone probably broke them again... happens quite often sadly...
>
> On Thu., Aug. 9, 2018, 9:05 p.m. Daniel Koć,  wrote:
>>
>> Hi,
>>
>> Is anybody aware what happened to Lake Superior and Lake Huron?
>>
>> https://www.openstreetmap.org/relation/4039486
>>
>> https://www.openstreetmap.org/relation/1205151
>>
>>
>> They were changed 20 and 3 days ago, respectively, and they stopped
>> being rendered both on default and on humanitarian map.
>>
>>
>> --
>> "My method is uncertain/ It's a mess but it's working" [F. Apple]

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

Re: [OSM-talk-fr] projet du mois : limite de vitesse 80/90 ?

[David Crochet]

Bonjour


Le 13/08/2018 à 13:23, Julien Lepiller a écrit :

donne une vitesse limite de « 30;50 ». C'est 30 ou 50 ? Qu'est-ce que
ça veut dire ? 


Quand tu regardes ce que tu peux voir, mais ce que tu ne peux pas 
utiliser, c'est qu'il y a un ralentisseur, donc un passage à 30


le chemin devrait être découpé en plusieurs morceaux afin d'y placer les 
bonnes limitations de vitesses dur les bonnes sections


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] projet du mois : limite de vitesse 80/90 ?

[Julien Lepiller]

Le 2018-08-12 22:53, osm.sanspourr...@spamgourmet.com a écrit :

Bonjour,

certes on peut continuer encore un moment du côté des postes de
distribution mais un sujet sans doute impactant plus les utilisateurs
sont les limites de vitesse.

Je pense que les maxspeed=90 n'ayant pas source:maxspeed=sign sont
tous à reprendre.


Si on parle de limites de vitesse, il y a aussi des limites bizarres
à vérifier. Par exemple :

https://www.openstreetmap.org/way/26565556

donne une vitesse limite de « 30;50 ». C'est 30 ou 50 ? Qu'est-ce que
ça veut dire ?

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

Re: [Talk-de] Datum einer Kontrolle vermerken?

[Volker Schmidt]

Zwei Ideen zum Thema:

1) delayed notes: Eine note bei der ich ein Datum eingeben, wann sie
sichtbar wird.

2) ich benutze das source tag um anzugeben, dass ich Gebäude verschoben
habe (oder neu hinzugefügt habe) in der Form:
source:position=Esri World Imagery
Hintergrund: in meiner Gegend sind fast alle Gebäude importiert mit einen
Positionsfehler von circa vier Metern. Manchmal verschiebe ich dann
Gebäude, um sie mit anderen Details kompatibel zu machen, z.B. Radwege oder
Fußwege.

On Mon, 13 Aug 2018, 09:25 gmbo,  wrote:

> Ich bin nicht der Meinung, dass so etwas gar nichts mit Geodaten zu tun
> hat, auch wenn nicht direkt. Dann müssten Daten wie Zeitpunkt der
> Eintragung Änderungsdaten usw auch verschwinden, denn sie haben direkt
> genausowenig damit zu tun wie die Speicherung der Changesets und Quellen.
> All diese Daten haben mit der Qualität und der Gültigkeit, also der
> Verläßlichkeit der Daten zu tun.
> OSM wäre aber nicht auf einem akzeptierten Stand wenn diese Daten fehlten.
>
> Im Fall der lastchecks geht ja dabei hauptsächlich um die Daten die sich
> verändern.
>
> Ja ich würde mir in dem Fall einen metatag wünschen den ich dabei aber
> gesteuert geben müsste, da sich sonst genau dann nichts tut wenn sich
> nichts geändert hat.
> Im Moment müsste ich also Beispielsweise den Namen eines Geschäftes
> löschen hochladen und dann wieder neu setzen um den wieder mit einem
> Metatag zu versehen.
> Das würde viel mehr Datenlast erzeugen wie ein zusätzlicher Tag der an
> sich erfahrungsgemäß häufig ändert.
>
> Als Beispiel eine Baustelle verhindert, dass man von Weg A nach Weg B
> kommt, weil ein Stück Straße gesperrt ist.
>
> Wenn ich so etwas gesetzt habe und nicht abschätzen kann wie lange das
> gültig ist, fahre ich normalerweise solche Punkt öfter an.
> Wenn ich es vergesse bleibt die Information sonst erheblich lange
> bestehen, wenn ich sie nicht eintrage fehlt sie.
>
> Ich fände es aber nicht richtig wenn ich eine solche Information nicht
> tagge weil ich das nicht kontrllieren kann und ich ja sehe dass ich mich
> gerade in einem Gebiet befinde wo wenig gemappt wird.
>
> Es wäre deshalb unserer Meinung nach gut, weil machbar, wenn es einen
> Tag gäbe, der in den Editoren angeboten würde um genau so ein Prüfbit zu
> setzen, in wieweit das bei Objekten mit vielen sich ändernden Tags dann
> verfeinert werden könnte sei dahingestellt, würde meiner Meinung nach
> nur noch geringe Verbesserungen bringen,
> Sas ganze würde zu einer höheren Qualität der Daten führen, es würde
> auch von Anfängern verstanden und einheilich, damit nutzbar gemacht.
>
>
> Kleie zusätzliche Anmerkung von mir:
> Wenn wir nur natürliche Eigenschaften von geografischen Objekten taggen
> würden wüssten wir es gibt dort einen Gipfel, oder eine Straße, der Name
> wäre ja auch keine natürliche geografische Eigenschaft, ist ja nur dazu
> da damit ein Mensch die erkennt und findet. Wenn das aber nicht in der
> DB wäre gäbe es OSM und damit die DB nicht mehr.
>
> Gruß
> Gisbert
>
>
> Am 12.08.2018 um 22:23 schrieb Michael Kugelmann:
> > Am 11.08.2018 um 13:08 schrieb Andreas Meier:
> >> die Information eines
> >> Verifikationsdatums ist m.E. eine Information, die an das Objekt gehört,
> >> weil sie als Metadaten die Qualität der Objektdaten beschreibt.
> > das Dateum einer Verifikation ist keine "natürliche Eigenschaft" eines
> > geographischen Objektes => hat mit dem Objekt in physikalischer Weise
> > nichts zu tun. Und genau das beschreiben wir is OSM => hat also m.E.
> > eindeutig nichts in der DB zu tun.
> >
> >
> > Just my 2 cents,
> > Michael.
> >
> >
> > ___
> > Talk-de mailing list
> > Talk-de@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-de
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Bilan du Projet du mois de juillet 2018 : les postes électriques

[deuzeffe]

Hello,

On 01/08/2018 02:34, François Lacombe wrote:


Si on regarde de plus près le mois de Juillet, 3557 objets ont été édits,
parmi lesquels :
307 postes poteaux
2975 postes en bâtiment
233 postes en armoire
42 postes de transport


Je suis allée faire un tour dans la campagne pour en repérer/intégrer 
d'autres, j'avance à mon (petit) rythme sur ma (minuscule) commune ;)


Cependant, un truc me chiffonne, c'est le rendu (carto ou fr). Je 
m'explique :

- les poteaux sont rendus par un point carré, sans indication (OK) ;
- les autres sont rendus par un point/une surface suivant les cas (ok) 
et le nom est... affiché, ce qui peut troubler la lecture de la carte.


Par ex. ici : https://osm.org/go/0AGkjbCnN

AU N, une armoire ("Grange Haut"), au S, un bâtiment ("Rue Théodore 
Monot", qui porte en plus le nom de la rue précédente si je ne m'abuse, 
mais faut que je vérifie le plan de nommage auprès de la commune - c'est 
en cours).


Bref, cet affichage des noms est perturbant, non ? Probablement parce 
qu'il manque les lignes (en aérien/souterrain)...


--
deuzeffe, c'est pas vital, mais...

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

Re: [Talk-cz] geograficke regiony v CR

[majka]

On Mon, 13 Aug 2018 at 12:40, Marián Kyral  wrote:

>
> Hmm: http://zemepis.zszlutice.cz/kabinety/zemepis/Cr-hory/hory.htm
>
> Jsem si jistý, že tohle jsem se ve škole neučili. Ale je pravda, že já
> ještě končil v osmičce.
>
Taky jsem koukala, protože to Plzeňsko shodou okolností byl referát odhadem
někdy ve čtvrté nebo páté třídě. Včetně té pahorkatiny. Žáci si mohli
vybrat, o jakém kraji budou vyprávět a měli si to připravit doma. Bylo mi
to přednášeno jako kontrola úkolu.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] geograficke regiony v CR

[Marián Kyral]

-- Původní e-mail --
Od: majka 
Komu: talk-cz@openstreetmap.org
Datum: 13. 8. 2018 12:34:43
Předmět: Re: [Talk-cz] geograficke regiony v CR
"




On Sun, 12 Aug 2018 at 22:57, Jan Macura mailto:macura...@gmail.com)> wrote:
"



Tak to jste troufalci. Kolikrát už jste to zkoušeli? Přijet třeba do Žinkov
a ptát se domorodců "japa se menuje tůta vaše geomorfologická oblast?" Kolik
odpovědí bylo "Nu to je přeci Plzeňská pahorkatina, panáčku!"?



"



Troufám si tvrdit, že jde jen o to, koho se zeptat. V daném případě žáka
základní školy
(http://www.unium.cz/materialy/0/0/ceska-republika-prirodni-podminky-m23518-p1.html)
, případně jeho rodičů.

Když jsem v Plzni, mám dvě takové žákyně po ruce a občas jsem nucená se s
nimi učit nebo dělat úkoly. 



""







Jen netuším, jestli "učí se to ve škole" je povolený zdroj dat ;)


"



Hmm: http://zemepis.zszlutice.cz/kabinety/zemepis/Cr-hory/hory.htm

Jsem si jistý, že tohle jsem se ve škole neučili. Ale je pravda, že já ještě
končil v osmičce.




Marián

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

Re: [Talk-cz] geograficke regiony v CR

[majka]

On Sun, 12 Aug 2018 at 22:57, Jan Macura  wrote:

> Tak to jste troufalci. Kolikrát už jste to zkoušeli? Přijet třeba do
> Žinkov a ptát se domorodců "japa se menuje tůta vaše geomorfologická
> oblast?" Kolik odpovědí bylo "Nu to je přeci Plzeňská pahorkatina,
> panáčku!"?
>

Troufám si tvrdit, že jde jen o to, koho se zeptat. V daném případě žáka
základní školy
,
případně jeho rodičů.
Když jsem v Plzni, mám dvě takové žákyně po ruce a občas jsem nucená se s
nimi učit nebo dělat úkoly.

Jen netuším, jestli "učí se to ve škole" je povolený zdroj dat ;)
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] geograficke regiony v CR

[Petr Vozdecký]

ahoj,

mohu se mylit, ale proc je dulezite to "on the ground"? Je spousta polozek,
ktere se nedaji pouhou navstevou mista zjistit, je nutne dalsi zjistovani a
patrani. Treba odlisne jazykove ci historicke nazvy sidel, mistni nazvy 
(treba i mene vyznamnych ci vyraznych bodu, nez jsou vrcholy)...

Obdobne tak hranice rezervaci ci chranenych uzemi (ano, sem-tam je cedule,
ale chci-li zakreslit presnou hranici, uprednostnim jine datove zdroje) a 
asi i pohori (byt zde netusim, zda a jak jsou definovana). Rovnou rikam, ze
nevidim duvod je nemapovat, jsou-li hranice a nazvy nejakou autoritou dany.

vop

-- Původní zpráva --
Od: Jan Macura
Datum: 10. 8. 2018 v 11:25:05
Předmět: Re: [Talk-cz] geograficke regiony v CR



Ahoj,




nemáte pocit, že tohle do OSM nepatří? Jak se zjišťují hranice a názvy
geomorfologických jednotek on the ground?




H.





2018-08-03 13:56 GMT+02:00 Martin Ždila mailto:martin.zd...@freemap.sk)>:
"


On Fri, Aug 3, 2018 at 1:39 PM Martin Ždila mailto:martin.zd...@freemap.sk)> wrote:

"


On Fri, Aug 3, 2018 at 1:22 PM Miroslav Suchy mailto:miros...@suchy.cz)> wrote:

"Podle me se tohle v OSM zatim neda mapovat.
"



Samozrejme ze sa to da, hoci zatial vlastnymi tagmi (co OSM nezakazuje). 
Priklad: https://www.openstreetmap.org/relation/1934489
(https://www.openstreetmap.org/relation/1934489)


"



Iny sposob tagovania: https://www.openstreetmap.org/way/279660793
(https://www.openstreetmap.org/way/279660793)

 

--


Ing. Martin Ždila(http://www.openstreetmap.org/user/*Martin*)

OZ Freemap Slovakia


tel:+421-908-363-848
mailto:martin.zd...@freemap.sk(mailto:martin.zd...@freemap.sk)
http://www.freemap.sk/(http://www.freemap.sk)






___
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)
https://openstreetmap.cz/talkcz(https://openstreetmap.cz/talkcz)

"




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

Re: [Talk-cz] Jak zmapovat návštěvnické centrum?

[Marián Kyral]

V Nošovicích jsem dal na budovu tourism=attraction a přidal extra POI pro
obchod se suvenýry.

https://www.openstreetmap.org/way/303680306




(Koukám, že tam mám typo :-O )





Marián




-- Původní e-mail --
Od: Mikoláš Štrajt 
Komu: OpenStreetMap Czech Republic 
Datum: 13. 8. 2018 10:47:21
Předmět: Re: [Talk-cz] Jak zmapovat návštěvnické centrum?
"Např. jaderná elektrárna temelín má návštěvnické (nebo spíš informační)
centrum s office=information a tourism=information.

Viz https://www.openstreetmap.org/node/1779042942

--
Severák
-- Původní e-mail --
Od: majka 
Komu: talk-cz@openstreetmap.org
Datum: 13. 8. 2018 10:15:44
Předmět: [Talk-cz] Jak zmapovat návštěvnické centrum?
"
Nějaké nápady, jak zmapovat návštěvnické centrum? Konkrétně pivovaru, kde se
pořádají prohlídky?



Jen jako tourism=attraction? Momentálně tam někdo hodil muzeum, což opravdu
odpovídá jen velmi vzdáleně.




Díky,

Majka

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

Re: [Talk-cz] Jak zmapovat návštěvnické centrum?

[Mikoláš Štrajt]

Např. jaderná elektrárna temelín má návštěvnické (nebo spíš informační)
centrum s office=information a tourism=information.

Viz https://www.openstreetmap.org/node/1779042942

--
Severák
-- Původní e-mail --
Od: majka 
Komu: talk-cz@openstreetmap.org
Datum: 13. 8. 2018 10:15:44
Předmět: [Talk-cz] Jak zmapovat návštěvnické centrum?
"
Nějaké nápady, jak zmapovat návštěvnické centrum? Konkrétně pivovaru, kde se
pořádají prohlídky?



Jen jako tourism=attraction? Momentálně tam někdo hodil muzeum, což opravdu
odpovídá jen velmi vzdáleně.




Díky,

Majka

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

Re: [OSM-talk-fr] projet du mois : limite de vitesse 80/90 ?

[Jérôme Seigneuret]

Bonjour,
Sauf que pour les 80 ou 90 ou 110 en soit il n'y a pas l'obligation d'avoir
un panneau.

Le code de la route dit
130 km/h sur les autoroutes ;
110 km/h sur les routes à deux chaussées séparées par un terre-plein
central ;
90 km/h sur les autres routes.
et maintenant on décompose le 90

90 sur les routes à double sens de circulation opposé avec un terre-plein
central
80 sur les routes n'ayant pas de séparateur et à double sens de circulation,
90 pour les doubles voies dans le même sens de circulation sans séparateur

Ducoup ce tableau dans le wiki est incomplet
FR:motorway 130 /110 (raining)
FR:rural 80
FR:urban 50

Le FR:rural est faux car c'est omettre des cas

On est sur un FR:rural80 et FR:rural90 et FR:trunk (FR:rural110) si l'on
considère une double voies avec séparateur à terre-plein central

Les valeurs ci-dessus sont implicites et ne nécessitent pas de panneaux
sauf à vouloir faire un rappel aux gens ayant du mal avec le code de la
route d'ailleurs j'ai essayé de voir le contenu du code et de la convention
de vienne et j'ai pas vu d'obligation de signalisation horizontale ou
verticale.

j'ai un problème avec le source
80, 90, 110 peuvent être du source=FR:rural car FR:rural est du hors agglo
en fait on ce retrouve sur du FR:rural avec des typicités structurelles:
 - type 80
 - type 90
 - type 110


Une route à simple voie peut aussi être élevé à 110 si le dépassement le
permet (à mon avis ça doit vraiment être rare en France) je connais une 3
voie 110 avec une voie au centre permettant le dépassement pour les deux
cotés de circulation (je passe pas mon temps sur la route donc vous avez
surement d'autres exemples)

Ducoup c'est comme en ville, si l'on doit passer à 70 ou à 30, on est
obligé d'informer physiquement avec des panneaux supplémentaires avec
rappel à chaque intersection sinon on revient à la vitesse par défaut
(sauf cas particulier des panneau carré mentionnant des zones 30 et 20)
Cela entraîne beaucoup de cas avec des forward backward car les communes et
services départementaux omettent souvent cette notion
De même sur route hors agglo avec du 70 ou 110 (et maintenant 90 si il le
veulent)
et sur autoroute 90 110  (70 ??? périphérique autoroutier)

on peux être sur une route de type 110 et avoir un maxspeed=90 avec un
source:maxspeed=sign

Dans tous les cas où un panneau est apparu c'est ducoup explicit et ça
impose aux DDE de faire une mise à jour des panneaux.
Dans ce cas source:maxspeed=sign pour moi c'est ok

Comme la notion de séparateurs sur les voies simple n'existe pas vraiment
hors relation on a un linéaire pour chaque voie séparée ducoup le
traitement automatique c'est pas vraiment l'idéal et je pense qu'il vaut
mieux traiter ça sous forme d'alerte pour en faire la vérification ou faire
un extract overpass pour traiter ces zones
On peut essayer de coupler ça avec un traitement spatial (voies parallèles
avec une distance particulière portant le même nom) > donc séparateur
physique

Ajouter source:maxspeed:date pour savoir si ça a été renseigné avant
2018-07 ou après me semble utile

Bonne journée



Le lun. 13 août 2018 à 05:36, Jérôme Amagat  a
écrit :

> D’après taginfo :
> Le 11 juillet :
> 90  95 044
> 80  10 967
>
> le  21 juillet :
> 90 91461
> 80 15126
>
> le 13 août :
> 90 83452
> 80 25193
>
> ça augmente mais pas très très vite :)
>
> La région Auvergne Rhône Alpes est à jour (sauf quelques cas où c'est pas
> simple avec seulement la vue aérienne)
>
> rappel du décret qui change la loi :
> https://www.legifrance.gouv.fr/eli/decret/2018/6/15/INTS1800012D/jo/texte
> en gros, il y a ça d'important :
> « 3° 80 km/ h sur les autres routes. Toutefois, sur les sections de ces
> routes comportant au moins deux voies affectées à un même sens de
> circulation, la vitesse maximale est relevée à 90 km/ h sur ces seules
> voies. Ces sections font l'objet d'une signalisation routière dans les
> conditions prévues par l'article R. 411-25. »
> (le reste du décret c'est : 80 par temps de pluie donc pareil qu'avant,
> les bus doivent aussi respecter les nouvelles limitations à 80 et les
> autorités doivent communiquer la liste des sections où la limite reste à 90
> parce qu'il y a 2 voies dans le même sens (ça serai bien qu'il la
> communique aussi en open data!))
>
> Donc pour moi :
> Les panneaux 90 d'avant le mois de juillet, sur les route qui d’après la
> loi sont passé de 90 à 80 km/h, il ne faut pas en tenir compte, ils ont
> disparus :)
>
> Le cas le plus simple, une route à double sens de circulation avec une
> voie dans chaque sens, je pense que ça devait représenter au moins 90% des
> maxspeed=90 dans osm, il faut les remplacer par maxspeed=80. ça il n'y a
> aucun doute, qu'il y ai des panneaux 90 avant ou pas.
>
> Le cas le plus simple où l'on ne touche pas au maxspeed=90 (ni à d'autres
> valeurs de maxspeed...) c'est sur les autoroutes et les chemin de fer :)
> (on peut y ajouter des highway=trunk en 2x2 voies avec chaussées séparées)
>
> Pour 

[Talk-cz] Jak zmapovat návštěvnické centrum?

[majka]

Nějaké nápady, jak zmapovat návštěvnické centrum? Konkrétně pivovaru, kde
se pořádají prohlídky?

Jen jako tourism=attraction? Momentálně tam někdo hodil muzeum, což opravdu
odpovídá jen velmi vzdáleně.

Díky,
Majka
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-au] City of Gold Coast / repeat requests of CC BY waivers

[Simon Poole]

Hi Graeme

Am 13.08.2018 um 09:24 schrieb Graeme Fitzpatrick:
> ...
>
> Don't know if anybody else on the Gold Coast may have asked for
> permission, or if they're taking my 2 - 3 contacts as multiple
> requests, rather than following up the original?
> ...
Could naturally be, they didn't give me details, so it is a bit
difficult to find out what has gone wrong (if anything). I can follow up
with them, maybe something simply got lost in the mail.

Simon

> Thanks
>
> Graeme
>
> On 13 August 2018 at 17:07, Simon Poole  > wrote:
>
> We've (as in the LWG) have received a mail from the City of Gold
> Coast concerning multiple repeat requests for CC BY waiver (no
> need to point out that that can be annoying). IMHO the AUS
> community already documents what is going on rather well
> https://wiki.openstreetmap.org/wiki/Australian_Data_Catalogue
>  so
> this may simply be a one off incident.
>
> So in any case, could you all try to avoid this happening as far
> as possible? While I don't quite see a Newbie sending such a
> request maybe it would be a good idea to send welcome mails and
> point to the list if that isn't already happening now (simplest
> way to do that is to get a new mapper RSS feed from Pascal Neis
> https://resultmaps.neis-one.org/newestosm?c=Australia#4/-29.68/133.30
> ).
>
> Thanks
>
> Simon
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-au
> 
>
>



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

[Talk-cz] WeeklyOSM CZ 419

[Tom Ka]

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

http://www.weeklyosm.eu/cz/archives/10557

* Web pro cyklovýlety.
* Fotky na freemap.sk.
* Výherci cen OSM 2018.
* Postřehy z Milána.
* Tagování výstavišť.
* Oblasti zájmu (AOI).
* Odhad kompletnosti OSM.
* Vektorové dlaždice pro osm.org?
* Stěhování OSM serverů.
* Uber přechází od Google Maps k OSM.
* Lua šablony pro OSM wiki.
* Další čtyři Galilea.

Pěkné počtení ...

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

Re: [Talk-de] Datum einer Kontrolle vermerken?

[gmbo]

Ich bin nicht der Meinung, dass so etwas gar nichts mit Geodaten zu tun 
hat, auch wenn nicht direkt. Dann müssten Daten wie Zeitpunkt der 
Eintragung Änderungsdaten usw auch verschwinden, denn sie haben direkt 
genausowenig damit zu tun wie die Speicherung der Changesets und Quellen.
All diese Daten haben mit der Qualität und der Gültigkeit, also der 
Verläßlichkeit der Daten zu tun.

OSM wäre aber nicht auf einem akzeptierten Stand wenn diese Daten fehlten.

Im Fall der lastchecks geht ja dabei hauptsächlich um die Daten die sich 
verändern.


Ja ich würde mir in dem Fall einen metatag wünschen den ich dabei aber 
gesteuert geben müsste, da sich sonst genau dann nichts tut wenn sich 
nichts geändert hat.
Im Moment müsste ich also Beispielsweise den Namen eines Geschäftes 
löschen hochladen und dann wieder neu setzen um den wieder mit einem 
Metatag zu versehen.
Das würde viel mehr Datenlast erzeugen wie ein zusätzlicher Tag der an 
sich erfahrungsgemäß häufig ändert.


Als Beispiel eine Baustelle verhindert, dass man von Weg A nach Weg B 
kommt, weil ein Stück Straße gesperrt ist.


Wenn ich so etwas gesetzt habe und nicht abschätzen kann wie lange das 
gültig ist, fahre ich normalerweise solche Punkt öfter an.
Wenn ich es vergesse bleibt die Information sonst erheblich lange 
bestehen, wenn ich sie nicht eintrage fehlt sie.


Ich fände es aber nicht richtig wenn ich eine solche Information nicht 
tagge weil ich das nicht kontrllieren kann und ich ja sehe dass ich mich 
gerade in einem Gebiet befinde wo wenig gemappt wird.


Es wäre deshalb unserer Meinung nach gut, weil machbar, wenn es einen 
Tag gäbe, der in den Editoren angeboten würde um genau so ein Prüfbit zu 
setzen, in wieweit das bei Objekten mit vielen sich ändernden Tags dann 
verfeinert werden könnte sei dahingestellt, würde meiner Meinung nach 
nur noch geringe Verbesserungen bringen,
Sas ganze würde zu einer höheren Qualität der Daten führen, es würde 
auch von Anfängern verstanden und einheilich, damit nutzbar gemacht.



Kleie zusätzliche Anmerkung von mir:
Wenn wir nur natürliche Eigenschaften von geografischen Objekten taggen 
würden wüssten wir es gibt dort einen Gipfel, oder eine Straße, der Name 
wäre ja auch keine natürliche geografische Eigenschaft, ist ja nur dazu 
da damit ein Mensch die erkennt und findet. Wenn das aber nicht in der 
DB wäre gäbe es OSM und damit die DB nicht mehr.


Gruß
Gisbert


Am 12.08.2018 um 22:23 schrieb Michael Kugelmann:

Am 11.08.2018 um 13:08 schrieb Andreas Meier:

die Information eines
Verifikationsdatums ist m.E. eine Information, die an das Objekt gehört,
weil sie als Metadaten die Qualität der Objektdaten beschreibt.
das Dateum einer Verifikation ist keine "natürliche Eigenschaft" eines 
geographischen Objektes => hat mit dem Objekt in physikalischer Weise 
nichts zu tun. Und genau das beschreiben wir is OSM => hat also m.E. 
eindeutig nichts in der DB zu tun.



Just my 2 cents,
Michael.


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




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

Re: [talk-au] City of Gold Coast / repeat requests of CC BY waivers

[Graeme Fitzpatrick]

Hi Simon

I may be the guilty party, but I'm not sure?

Did contact GCCC earlier this year for permission to use data, which they
gave.

However, I'd forgotten to ask them for the waiver, so went back to them a
couple of days later to ask for that.

Lady I spoke to thought it would be OK, but had to pass it to (I assume)
their legal section.

A couple of months ago, she followed up with legals to check on progress &
cc'ed me to say it should be resolved soon.

About 2 weeks ago, I followed up with her as hadn't heard anything. She
passed it to legals again & cc'ed me.

I then got an e-mail from legals asking who I was & what company I
represent.

Sent them another copy of the basic "I'm an OSM contributor" letter
together with the fact sheet, but haven't heard anything more since then.

Don't know if anybody else on the Gold Coast may have asked for permission,
or if they're taking my 2 - 3 contacts as multiple requests, rather than
following up the original?

Thanks

Graeme

On 13 August 2018 at 17:07, Simon Poole  wrote:

> We've (as in the LWG) have received a mail from the City of Gold Coast
> concerning multiple repeat requests for CC BY waiver (no need to point out
> that that can be annoying). IMHO the AUS community already documents what
> is going on rather well https://wiki.openstreetmap.
> org/wiki/Australian_Data_Catalogue so this may simply be a one off
> incident.
> So in any case, could you all try to avoid this happening as far as
> possible? While I don't quite see a Newbie sending such a request maybe it
> would be a good idea to send welcome mails and point to the list if that
> isn't already happening now (simplest way to do that is to get a new mapper
> RSS feed from Pascal Neis https://resultmaps.neis-one.
> org/newestosm?c=Australia#4/-29.68/133.30).
>
> Thanks
>
> Simon
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-GB] New Ghosts Set and Survey Me Auto-Location Feature

[Shaun McDonald]

> On 7 Aug 2018, at 10:53, Richard Fairhurst  wrote:
> 
> Philip Barnes wrote:
>> Recently new blue branded co-op shops have started to appear, 
>> some have changed and at least one has opened in direct 
>> competition with an existing Mid-counties.
> 
> Midcounties are also adopting the "new" cloverleaf Co-op logo in many
> places, while their Chipping Norton shop, curiously, uses the Co-operatives
> UK logo. There's so much overlap (particularly between Midcounties and the
> Co-operative Group) that they really need to be surveyed to find the
> operator, which I agree would be useful information.
> 
> Shipston-on-Stour has two Co-ops literally three doors away from each other
> - one Midcounties, one Co-operative Group (ex-Somerfield).
> 

There’s also a big overlap in places like Edinburgh due to Co-op buying the 
Somerfield stores several years ago. This means that some newer stores accept 
the loyalty cards, whilst the older ones don’t.

Shaun


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

[talk-au] City of Gold Coast / repeat requests of CC BY waivers

[Simon Poole]

We've (as in the LWG) have received a mail from the City of Gold Coast
concerning multiple repeat requests for CC BY waiver (no need to point
out that that can be annoying). IMHO the AUS community already documents
what is going on rather well
https://wiki.openstreetmap.org/wiki/Australian_Data_Catalogue so this
may simply be a one off incident.

So in any case, could you all try to avoid this happening as far as
possible? While I don't quite see a Newbie sending such a request maybe
it would be a good idea to send welcome mails and point to the list if
that isn't already happening now (simplest way to do that is to get a
new mapper RSS feed from Pascal Neis
https://resultmaps.neis-one.org/newestosm?c=Australia#4/-29.68/133.30).

Thanks

Simon


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

Re: [OSM-talk-fr] audit des panneaux

[Jérôme Seigneuret]

Fabuleux ;-)
Merci pour ce bel exemple.

Le dim. 12 août 2018 à 22:49,  a écrit :

> Le 12/08/2018 à 19:11, Jérôme Seigneuret - jerome.seigneu...@gmail.com a
> écrit :
>
>
> Faites un audit des panneaux et marquage de votre commune et vous allez
> bien rire jaune.
>
> Bonne soirée,
> Jérôme
>
> On a le droit à d'autres communes ?
> https://www.openstreetmap.org/#map=19/48.31241/-4.55191
> Là en plus vous avez l'histoire du panneau.
>
> Parce qu'un (1) taré roulait à route allure, la municipalité a décider de
> baliser le tronçon du Chemin de Kerhuel en zone de rencontre. Verbaliser ça
> aurait été trop simple et trop efficace.
> Panneau de début de zone à l'ouest, fin de zone à l'est.
> Jusque là rien à rien. Sauf que les gens venant de l'ouest n'ont que le
> panneau de début de zone et les gens venant de l'ouest que le panneau de
> fin.
> Donc règlementairement toute la commune de Roscanvel est ainsi passée en
> zone de rencontre.
>
> Jean-Yvon
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [Talk-cz] nenalezené spojení

[jozka]

To neni jen v CR. Maj to rozbity.

J.

__
> Od: 
> Komu: 
> Datum: 13.08.2018 01:53
> Předmět: [Talk-cz] nenalezené spojení
>
>Ahoj,
>mohl bych vás požádat o radu s navigací v mapách? Používám zkompilovaný 
>osrm-routed a nedaří se mi nalézt spojení mezi 2 body v ČR.
> 
>Zkoušel jsem to tedy na stránkách www.openstreetmap.org a tam jsem dopadl 
>stejně (někdy to spojení vyhledá a někdy ne).
>https://www.openstreetmap.org/directions?engine=osrm_car=50.3539%2C14.7865%3B50.1066%2C14.2694
> 
>Start by měl být zde: 50.359955,14.791098 a cíl zde: 50.1066, 14.2694.
> 
>Takových míst mám víc.
> 
>Děkuji za radu,
>Ivan
>
>
>
>--
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>https://openstreetmap.cz/talkcz
>
>

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

[Talk-cz] nenalezené spojení

[ivan.kral83]

Ahoj,
mohl bych vás požádat o radu s navigací v mapách? Používám zkompilovaný 
osrm-routed a nedaří se mi nalézt spojení mezi 2 body v ČR.
 
Zkoušel jsem to tedy na stránkách www.openstreetmap.org a tam jsem dopadl 
stejně (někdy to spojení vyhledá a někdy ne).
https://www.openstreetmap.org/directions?engine=osrm_car=50.3539%2C14.7865%3B50.1066%2C14.2694
 
Start by měl být zde: 50.359955,14.791098 a cíl zde: 50.1066, 14.2694.
 
Takových míst mám víc.
 
Děkuji za radu,
Ivan

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