Re: [OSM-talk-be] int_ref, ref spelling, no space between letter and number....

[Marc Gemis]

When you search for "blank" on Wikipedia, you will find some
disambiguation pages (a.o https://en.wikipedia.org/wiki/Blank_space),
and finally end up on :
https://en.wikipedia.org/wiki/Space_(punctuation)
So space is correct.

m.

p.s. Do we need to ask people not to write in Dutch whenever they
violate the dt-rule ? :-)
p.p.s Do you read the Dutch forum ? I sometimes have to read certain
posts 3 or 4 times to understand the "Dutch" that is used there. So I
do not bother the occasional typo in English.
On Sat, Aug 11, 2018 at 3:49 PM Karel Adams  wrote:
>
> Thanks, Jo, you are looking on from a little distance, that is always helpful 
> to get consensus...
>
> I agree with your "the key to create such a blank is commonly known as the 
> space bar" - which only confirms how subtle the English language really is. 
> And that is precisely what makes me contest the "rule" cited by @Ruben 
> (he/she is right in the citation, but I defy the rule) "on this list the 
> accepted standard is to use English" - I never liked that rule, mostly for 
> this reason. There's all too many people who post (to some degree) gibberish, 
> in the firm belief they have good English.
>
> And to come back to @Ruben's reply "no-one would have failed to understand 
> what we meant": try taking this conversation though some www translation tool 
> to an exotic language, say Japanese or Swahili or Latin or Basque, than back 
> to English. Without having checked, I dare to bet that somewhere in the 
> process the "space" was converted to something astronautical. So yes, I am 
> sure many people might get confused. Or in other words, what's the added 
> value of posting in a language that is NOT native to this Belgian country? 
> Except of course to oblige those few who prefer learning foreign languages 
> over learning their own.
>
> Karel (admittedly touchy on matters of language and local culture)
>
>
> On 11/08/18 13:31, Jo wrote:
>
> Karel, you are probably right, but the key to create such a blank is commonly 
> known as the space bar.
>
> I would also remove the 'empty character' (Leerzeichen) here in Belgium.
>
> In France it's consistently with a space, I guess they find it like that on 
> their signage.
>
> Jo
>
> Op za 11 aug. 2018 om 15:11 schreef Karel Adams :
>>
>> Excuse me for being pecky on language - for this once I feel free
>> because language is (more or less) the subject matter anyway.
>>
>> Where @jakka writes "space", and @ruben neatly follows suit, I think the
>> actual meaning is "blank".
>>
>> nl "spatie" => en "blank"
>>
>> en "space" => nl "ruimte"
>>
>> Not wanting to "score" any personal hits, just for the common good:
>> allow me to recommend that English should only be used by those who
>> master that subtle language really well. There is no reason for not
>> posting in one's native language, on a list of regional importance such
>> as this.
>>
>> Groeten :)
>>
>> Karel
>>
>>
>> On 11/08/18 12:38, Ruben wrote:
>> > Hi Frank,
>> >
>> > On Fri, 10 Aug 2018 21:06:54 +0200, Jakka  wrote:
>> >> Where can I see and read what is the correct spelling of the E and other 
>> >> road network like A? Is there a space between the letter and number?
>> >> The wiki pages 
>> >> https://wiki.openstreetmap.org/wiki/WikiProject_Europe/E-road_network and 
>> >> https://en.wikipedia.org/wiki/International_E-road_network are not clear 
>> >> about that...
>> >> See the mapillary https://www.mapillary.com/map/im/vEtPrDgYQ9nVD2kfehABQg 
>> >> example: there are no spaces so should we adapt all those tags?
>> > I believe our local refs are without space (so "A17", "R0", "N540"). Our 
>> > signposting for international refs doesn't use a space either (E40), or 
>> > sometimes a 'thin space' (E 40). I've never seen a full space (E 40).
>> > On their site[1], the Flemish Agency for Roads and Traffic (AWV) 
>> > consistently uses no space for both local and E refs. So I'd be inclined 
>> > to say it's without space.
>> >
>> >> I see that most of int_ref is with space and ref and nat_ref without? But 
>> >> not always...
>> > A few years ago, a French mapper came along and mechanically edited 
>> > int_refs in Belgium. I asked them to stop but their changes were never 
>> > fully reverted, so there are still int_refs with a space in Belgium.
>> > I think it would be safe to remove the spaces mechanically, as it would 
>> > actually be reverting an earlier unauthorized mechanical edit. What do you 
>> > think?
>> >
>> > [1] https://wegenenverkeer.be/
>> >
>> > Cheers,
>> > Ruben
>> >
>> > ___
>> > Talk-be mailing list
>> > Talk-be@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> 

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

[Jérôme Amagat]

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 les voies qui ne sont pas à chaussés séparées et ont au moins 2 voies
dans le même sens c'est 90 seulement dans le sens où il y a 2 voies :
ça veux dire :
4 voies en 2 fois 2 on garde maxspeed=90
3 voies : pas de maxspeed=* mais il faut utiliser maxspeed:forward=* et
maxspeed:backward=*
(il y a le cas particulier avec 3 voies avec celle du milieu qui sert pour
doubler dans les 2 sens là pas de doute c'est maxspeed=80)
Dans ces cas où la limite c'est 90 des panneaux ont été ajouté sur ces
routes.
sur le papier c'est simple mais qu'est ce qui se passe si tout semble
indiqué que l'on est dans le cas de 2 voies dans le même sens donc 90 mais
il n'y a pas de panneau et en plus sur la vue aérienne on les voit pas ces
panneaux :)

si il y a 2 (ou plus) voies dans le même sens :
Si une des voie est une voie d'insertion ou de sortie ou que les voies ne
servent pas a aller au même endroit avec des flèches au sol c'est 80km/h.
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.
Dans ces cas j'ai fait un choix ou aucun choix :) en laissant maxspeed=90
ou en passant à 80.

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

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

conclusion :)
La plupart des way dans osm avec maxspeed=90  sont simples a juger si il
faut changer en maxspeed=80 avec l'aide de la vue aérienne donc il faut
faire baisser ces 83000 maxspeed=90 !
Il y a des cas où c'est plus compliqué voir impossible a savoir avec
seulement la vue aérienne mais pas tant de cas que ça :)
il est aussi facile de s'occuper dans la plupart des cas des radars fixes
vu que l'on connaît la limite de vitesse sur la route...)

Pour ce qui ai des source:maxspeed, des FR:rural, des maxspeed:type ... je
n'y ai jamais touché (avant ou après le mois de juillet), je trouve ça pas
clair du tout et inutile . pour moi l'important c'est le tag maxspeed=*. ça
devait être utile en cas de changement de règle du code de la route et on
voit bien aujourd'hui que ça l'ai pas du tout :)

dans overpass turbo, on peut télécharger tous les éléments avec maxspeed=90
( en excluant chemins de fer, autoroutes et sorties d'autoroutes avec ça :
https://overpass-turbo.eu/s/AZX
___
Talk-fr mailing list
Talk-fr@openstreetmap.org

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[OSM Volunteer stevea]

Je suis certainement conscient des différences entre le Québec et la France. 
Pas comme un Canadien natal, bien sûr. C'est pourquoi j'ai dit "pour choisir 
l'une des nombreuses villes que j'ai embarquées dans les trains."  Je ne suis 
pas monté à bord du train de banlieue canadien ou VIA (j’ai presque fait 
pendant les vacances) et le RER à Paris ne semble pas comparer des pommes et 
des hippopotames.

Il semble que mes commentaires sérieux ne soient pas les bienvenus ou invitent 
à la recherche de la moindre erreur.  Résumé très facile:  S'il vous plaît 
nommez vos systèmes de transport comme bon vous semble pour les francophones de 
Montréal en utilisant une bonne syntaxe OSM et nous pourrons tous profiter de 
notre été.

Je propose simplement des suggestions qui, je l’espère, favoriseraient une 
bonne cohérence entre les États-Unis, le Canada et le monde entier d’OSM et 
continueraient d’atteindre cet objectif.

Bonne journée,

Etienne
Californie

> On Aug 12, 2018, at 4:59 PM, James  wrote:
> 
> Résumé très facile: Paris ou la france ≠ Le Québec. 
> Le Québec fait les chose très différente de la France.
> 
> On Sun., Aug. 12, 2018, 8:36 p.m. OSM Volunteer stevea, 
>  wrote:
> Ayant embarqué à bord de nombreux trains à Paris (pour choisir l'une des 
> nombreuses villes que j'ai embarquées dans les trains), OSM aux Halles dit 
> "operator=RATP" et "name=RER B". Certains disent que la pure consistance est 
> stupide. Je dis "trouver ce qui fonctionne et rester cohérent".
> 
> Jusqu'à ce que v1 devienne v2 ou v2 devient v3; une telle croissance se 
> produit. Joli bavard avec toi, Canada.
> 
> Etienne
> Californie
> 
> > On Aug 12, 2018, at 3:45 PM, James  wrote:
> > 
> > Personellement la STM est connu sous la STM sur toute la "branding" (bus, 
> > arrêts, site web(stm.ca), etc) La seule exception est que son nom légale 
> > est : Société de Transport de Montréal. Pareil pour la STO à 
> > Gatineau(Société de Transport  de l'Outaouais)
> 


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

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[James]

Résumé très facile: Paris ou la france ≠ Le Québec.
Le Québec fait les chose très différente de la France.

On Sun., Aug. 12, 2018, 8:36 p.m. OSM Volunteer stevea, <
stevea...@softworkers.com> wrote:

> Ayant embarqué à bord de nombreux trains à Paris (pour choisir l'une des
> nombreuses villes que j'ai embarquées dans les trains), OSM aux Halles dit
> "operator=RATP" et "name=RER B". Certains disent que la pure consistance
> est stupide. Je dis "trouver ce qui fonctionne et rester cohérent".
>
> Jusqu'à ce que v1 devienne v2 ou v2 devient v3; une telle croissance se
> produit. Joli bavard avec toi, Canada.
>
> Etienne
> Californie
>
> > On Aug 12, 2018, at 3:45 PM, James  wrote:
> >
> > Personellement la STM est connu sous la STM sur toute la "branding"
> (bus, arrêts, site web(stm.ca), etc) La seule exception est que son nom
> légale est : Société de Transport de Montréal. Pareil pour la STO à
> Gatineau(Société de Transport  de l'Outaouais)
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[OSM Volunteer stevea]

Ayant embarqué à bord de nombreux trains à Paris (pour choisir l'une des 
nombreuses villes que j'ai embarquées dans les trains), OSM aux Halles dit 
"operator=RATP" et "name=RER B". Certains disent que la pure consistance est 
stupide. Je dis "trouver ce qui fonctionne et rester cohérent".

Jusqu'à ce que v1 devienne v2 ou v2 devient v3; une telle croissance se 
produit. Joli bavard avec toi, Canada.

Etienne
Californie

> On Aug 12, 2018, at 3:45 PM, James  wrote:
> 
> Personellement la STM est connu sous la STM sur toute la "branding" (bus, 
> arrêts, site web(stm.ca), etc) La seule exception est que son nom légale est 
> : Société de Transport de Montréal. Pareil pour la STO à Gatineau(Société de 
> Transport  de l'Outaouais)


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

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

[osm . sanspourriel]

> Et pour bien rappeler que 3 voies, c'est 90, des panneaux 90 ont été 
ajoutés.


Non deuzeffe, comme je précise c'est 80 mais la collectivité responsable 
a le droit de passer à 90 et sous conditions. Si c'était le cas, il n'y 
aurait ni un panneau de limitation (90 - car on resterait à la vitesse 
par défaut) ni un panneau de fin de limitation (car on resterait à la 
vitesse par défaut).


Le 12/08/2018 à 23:38, marc marc - marc_marc_...@hotmail.com a écrit :

Bonsoir,

Le 12. 08. 18 à 23:21,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

De plus en général on évite type qui est un mot valise pour un plus 
précis (maxspeed:origin par exemple).
source: est un préfixe pour la catégorisation des sources. 
source:name:br indique par exemple l'origine du name:br.



on trouve des panneaux 80.

vu qu'il y a un panneau, je mettrait sign
parce que si demain une loi passe pour changer la vitesse par défaut,
la limite restera tant que le panneau n'est pas changé ou supprimé.

D'accord avec deuzeffe : on a eu un cas pratique !
Et tu vas découper la route à la première intersection pour passer de 
sign à FR:rural ?
Par défaut le panneau a été supprimé ou remplacé. Donc ta source ne vaut 
plus rien.



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

Oui c'est un bon endroit à aller voir sur place ce qu'il en est.
A distance j'ai du mal à voir comment on pourrait prédire s'il y a
toujours un panneau 90 ou pas.
non s'il n'y a pas deux voies dans le même sens, c'est 80, seulement si 
c'est  deux voies dans le même sens et ça l'imagerie aérienne suffit à 
mettre 80.
Et qu'il n'y a pas d'imagerie terrestre récente permettant de voir le 
panneau. Dans tout l'ouest de la Bretagne j'ai eu un seul cas ou 
l'imagerie aérienne ne permettait pas de conclure (90 possible, pas 
d'imagerie terrestre dispo).

Reste que des maxspeed=90 source:maxspeed=sign

datant d'avant juillet 2018 n'ont pas lieu d'être.

je ne comprend pas ce que tu veux dire.
si le panneau 90 est tjs là, il s'applique non ?
sauf à supposer que tout les panneaux du pays ont été changé.

Déjà oui, comme dit par deuzeffe, 99 % des panneaux à 90 ont changé.
Ce que je dis c'est que si tu as une imagerie datant d'avant le 1er 
juillet, tu ne dois pas l'utiliser parce que tu ne sais si le panneau 
est encore en place.
Par défaut le panneau a été supprimé ou remplacé. Donc ta source datée 
ne vaut plus rien.


Dans la pratique :
- ancienne voie de dépassement, si visiblement juste une voie de 
dépassement avant il n'y avait pas de panneau, éventuellement un 90 
rappel. Aujourd'hui c'est soit rien soit 90.
- ancienne fin de limitation de vitesse, on ne devrait rien avoir à 
faire hormis passer le 90 à 80.
- ancienne 4 voies non voie expresse ou autoroute, on avait des 90, sans 
toute sign, éventuellement FR:rural, maintenant c'est du sign (si 
vitesse maintenue ce qui est probable, exemple D 100, contournement nord 
de Quimper ).


Après pour les 90 non sourcés, je pense que ça va devenir pour 
l'essentiel des 80, FR:rural. Les 3/4 voies non voies expresses et non 
autoroutes, ça ne court pas les rues. Car les rues c'est FR:urban -;).


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

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[James]

Personellement la STM est connu sous la STM sur toute la "branding" (bus,
arrêts, site web(stm.ca), etc) La seule exception est que son nom légale
est : Société de Transport de Montréal. Pareil pour la STO à
Gatineau(Société de Transport  de l'Outaouais)

On Sun., Aug. 12, 2018, 7:39 p.m. OSM Volunteer stevea, <
stevea...@softworkers.com> wrote:

> "Raise matters" isn't something I did, it is something I am doing, as in
> continuing dialog.  Donc, merci pour la suggestion, mes deux années
> d'écolier français devront suffire.  This discussion did start in English.
> If you think a wiki page with a simple table sketches out "here's how we do
> this" (we've got one here for BART,
> https://wiki.osm.org/wiki/Bay_Area_Rapid_Transit and it syncs with
> https://wiki.osm.org/wiki/California/Railroads ) as in "it doesn't take
> much effort to say 'do it like this,'" hey, great.  I'm all for that sort
> of documentation and consistency and "let's communicate well."
>
> Really, some guy in California and some guy in a larger neighboring
> country (with the longest, perhaps most lightly-protected border on Earth,
> displaying obvious trust, history and centuries of good will) having a
> discussion about improving/developing transport tagging doesn't seem it
> should feel this antagonistic.  Abbreviate, or don't.  Pay attention to
> infrastructure tagging, or don't.  More (or less) closely align with USA
> and OpenRailWay mapping conventions (there are differences, it makes sense
> for countries to say "here's how WE do it" and "here's how we AND OUR
> NEIGHBORS do it" makes sense for trains and bus schedules and bike routes.
> Or don't.  These things really are international and good dialog makes good
> protocols.  We're simply people talking on a mailing list; I happen to
> believe that it's good that we do.
>
> Good dialog is good OSM.
>
> SteveA
> California
>
> (DJT, not JDT, of course)
>
> > On Aug 12, 2018, at 3:15 PM, john whelan  wrote:
> >
> > If you wish to raise matters about local mapping in Montreal I suggest
> you use French as it is the language that most Montreal mappers are
> familiar with.
> >
> > Cheerio John
> >
> > On 12 August 2018 at 17:37, OSM Volunteer stevea <
> stevea...@softworkers.com> wrote:
> > John, especially in light that we both volunteer in a wonderful
> organization like OSM, I consider neither of us poor.  Truly, I mean that.
> >
> > It wouldn't be "confused" that I might be.  It would be much more
> leaning towards, if not firmly in, the camp of "abbreviating in OSM
> key:value pairs is frowned upon because it maps backwards incompletely."
> That is a fair logical/mathematical/linguistic/database point.  Getting
> line-renderers to pay attention to short_name or alt_name or local_name or
> coalesce on something sensible, sure, that's a happy place.  I'd love to
> see a transport renderer that is wicked-smart with v2 and even v3 savvy
> colors, naming, routes and a "visual pop" that a good map does simply as
> you look at it.  That starts with good tagging including good discussion
> about tagging.  Simple as walking.
> >
> > Politics aside and whether hordes flee JDT or not, I am talking about
> good tagging in OSM as transport networks and how they are named and "get
> smart" really is happening all over Earth.  Good protocols to "we're all
> paying attention together" works.  Whether ISO/UN/IEEE or other acronyms
> and how a committee really can get the phones to connect and the trains
> running on time, the ideas behind "let's agree on good language and
> tagging..." work, this is simply being good neighbors.  A big human family
> sharing a map acts like a big human family sharing a map.  We seem to
> continue to do that here in talk-ca, talk-us and so on.  Thank you.
> >
> > SteveA
> > California
> >
> > > On Aug 12, 2018, at 2:17 PM, john whelan 
> wrote:
> > >
> > > Good heavens you mean we should spell out OCtranspo as Ottawa Carleton
> Transpo in case any American tourists get confused?
> > >
> > > Unfortunately the locals will probably get confused with this and
> whilst we should cater to these foreign tourists I think what is on the
> signs locally will be less confusing to the locals unless of course we get
> many more people streaming in to escape Donald.
> > >
> > > Or have I misunderstood some poor American?
> > >
> > > Cheerio John
> > >
> > > On Sun, 12 Aug 2018, 4:48 pm OSM Volunteer stevea, <
> stevea...@softworkers.com> wrote:
> > > Dusting off a month-old thread...
> > >
> > > Damien and Jarek, it seems the examples listed below both fit into a
> "citizen mappers coalescing on a local/regional way to do things" as well
> as a "somebody unfamiliar with Canadian transport mapping w.r.t. naming,
> network and operator tag conventions" (maybe who reads our wikis, maybe who
> does OT queries...) can figure this out quickly and sensibly.  It's great
> to see that's where things have landed, pretty close to a
> sweet-spot/bullseye.
> > >
> > > However (if I have 

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

[Andreas Meier]

Ich bin nicht sicher, ob Datenbank-timestamps nicht der falsche Weg sind.

Nach meinem Gefühl (mehr ist es im Moment nicht) sind das automatisiert
erzeugte Metadaten, die die Datenbank für ihre interne technische
Integritätsprüfung bzw. –nachweis braucht.

 

Das „habe-gecheckt“-Tag wäre aber doch eher eine manuell gesetzte
(Meta-)Information auf der gleichen Ebene wie alle anderen Tags, die ein
Mapper willentlich dokumentiert oder auch nicht.

 

Beide Ebenen zu vermischen scheint mir nicht sauber.

Viele Grüße

Andreas

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

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

[Volker]

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
Nochmal +1, obwohl ich das weiter aoben schon mal sinngemäß geschrieben 
habe und fast "gesteinigt" wurde :-I


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

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[OSM Volunteer stevea]

"Raise matters" isn't something I did, it is something I am doing, as in 
continuing dialog.  Donc, merci pour la suggestion, mes deux années d'écolier 
français devront suffire.  This discussion did start in English.  If you think 
a wiki page with a simple table sketches out "here's how we do this" (we've got 
one here for BART, https://wiki.osm.org/wiki/Bay_Area_Rapid_Transit and it 
syncs with https://wiki.osm.org/wiki/California/Railroads ) as in "it doesn't 
take much effort to say 'do it like this,'" hey, great.  I'm all for that sort 
of documentation and consistency and "let's communicate well."

Really, some guy in California and some guy in a larger neighboring country 
(with the longest, perhaps most lightly-protected border on Earth, displaying 
obvious trust, history and centuries of good will) having a discussion about 
improving/developing transport tagging doesn't seem it should feel this 
antagonistic.  Abbreviate, or don't.  Pay attention to infrastructure tagging, 
or don't.  More (or less) closely align with USA and OpenRailWay mapping 
conventions (there are differences, it makes sense for countries to say "here's 
how WE do it" and "here's how we AND OUR NEIGHBORS do it" makes sense for 
trains and bus schedules and bike routes.  Or don't.  These things really are 
international and good dialog makes good protocols.  We're simply people 
talking on a mailing list; I happen to believe that it's good that we do.

Good dialog is good OSM.

SteveA
California

(DJT, not JDT, of course)

> On Aug 12, 2018, at 3:15 PM, john whelan  wrote:
> 
> If you wish to raise matters about local mapping in Montreal I suggest you 
> use French as it is the language that most Montreal mappers are familiar with.
> 
> Cheerio John
> 
> On 12 August 2018 at 17:37, OSM Volunteer stevea  
> wrote:
> John, especially in light that we both volunteer in a wonderful organization 
> like OSM, I consider neither of us poor.  Truly, I mean that.
> 
> It wouldn't be "confused" that I might be.  It would be much more leaning 
> towards, if not firmly in, the camp of "abbreviating in OSM key:value pairs 
> is frowned upon because it maps backwards incompletely."  That is a fair 
> logical/mathematical/linguistic/database point.  Getting line-renderers to 
> pay attention to short_name or alt_name or local_name or coalesce on 
> something sensible, sure, that's a happy place.  I'd love to see a transport 
> renderer that is wicked-smart with v2 and even v3 savvy colors, naming, 
> routes and a "visual pop" that a good map does simply as you look at it.  
> That starts with good tagging including good discussion about tagging.  
> Simple as walking.
> 
> Politics aside and whether hordes flee JDT or not, I am talking about good 
> tagging in OSM as transport networks and how they are named and "get smart" 
> really is happening all over Earth.  Good protocols to "we're all paying 
> attention together" works.  Whether ISO/UN/IEEE or other acronyms and how a 
> committee really can get the phones to connect and the trains running on 
> time, the ideas behind "let's agree on good language and tagging..." work, 
> this is simply being good neighbors.  A big human family sharing a map acts 
> like a big human family sharing a map.  We seem to continue to do that here 
> in talk-ca, talk-us and so on.  Thank you.
> 
> SteveA
> California
> 
> > On Aug 12, 2018, at 2:17 PM, john whelan  wrote:
> > 
> > Good heavens you mean we should spell out OCtranspo as Ottawa Carleton 
> > Transpo in case any American tourists get confused?
> > 
> > Unfortunately the locals will probably get confused with this and whilst we 
> > should cater to these foreign tourists I think what is on the signs locally 
> > will be less confusing to the locals unless of course we get many more 
> > people streaming in to escape Donald.
> > 
> > Or have I misunderstood some poor American?
> > 
> > Cheerio John
> > 
> > On Sun, 12 Aug 2018, 4:48 pm OSM Volunteer stevea, 
> >  wrote:
> > Dusting off a month-old thread...
> > 
> > Damien and Jarek, it seems the examples listed below both fit into a 
> > "citizen mappers coalescing on a local/regional way to do things" as well 
> > as a "somebody unfamiliar with Canadian transport mapping w.r.t. naming, 
> > network and operator tag conventions" (maybe who reads our wikis, maybe who 
> > does OT queries...) can figure this out quickly and sensibly.  It's great 
> > to see that's where things have landed, pretty close to a 
> > sweet-spot/bullseye.
> > 
> > However (if I have to "spoil" a good thing, oh, well, this is a discussion 
> > forum...) I do think that operator=RATP is a bit curt even as "tout le 
> > monde à Paris sait ce que signifie la RATP."  (I recall being asked in a 
> > Regional Transportation Commission meeting what AASHTO stood for and I got 
> > it wrong, but then quickly got it right on the next try seconds later, 
> > alas, "too late").  It is true that an OSM convention is name=Saint 

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[john whelan]

If you wish to raise matters about local mapping in Montreal I suggest you
use French as it is the language that most Montreal mappers are familiar
with.

Cheerio John

On 12 August 2018 at 17:37, OSM Volunteer stevea 
wrote:

> John, especially in light that we both volunteer in a wonderful
> organization like OSM, I consider neither of us poor.  Truly, I mean that.
>
> It wouldn't be "confused" that I might be.  It would be much more leaning
> towards, if not firmly in, the camp of "abbreviating in OSM key:value pairs
> is frowned upon because it maps backwards incompletely."  That is a fair
> logical/mathematical/linguistic/database point.  Getting line-renderers
> to pay attention to short_name or alt_name or local_name or coalesce on
> something sensible, sure, that's a happy place.  I'd love to see a
> transport renderer that is wicked-smart with v2 and even v3 savvy colors,
> naming, routes and a "visual pop" that a good map does simply as you look
> at it.  That starts with good tagging including good discussion about
> tagging.  Simple as walking.
>
> Politics aside and whether hordes flee JDT or not, I am talking about good
> tagging in OSM as transport networks and how they are named and "get smart"
> really is happening all over Earth.  Good protocols to "we're all paying
> attention together" works.  Whether ISO/UN/IEEE or other acronyms and how a
> committee really can get the phones to connect and the trains running on
> time, the ideas behind "let's agree on good language and tagging..." work,
> this is simply being good neighbors.  A big human family sharing a map acts
> like a big human family sharing a map.  We seem to continue to do that here
> in talk-ca, talk-us and so on.  Thank you.
>
> SteveA
> California
>
> > On Aug 12, 2018, at 2:17 PM, john whelan  wrote:
> >
> > Good heavens you mean we should spell out OCtranspo as Ottawa Carleton
> Transpo in case any American tourists get confused?
> >
> > Unfortunately the locals will probably get confused with this and whilst
> we should cater to these foreign tourists I think what is on the signs
> locally will be less confusing to the locals unless of course we get many
> more people streaming in to escape Donald.
> >
> > Or have I misunderstood some poor American?
> >
> > Cheerio John
> >
> > On Sun, 12 Aug 2018, 4:48 pm OSM Volunteer stevea, <
> stevea...@softworkers.com> wrote:
> > Dusting off a month-old thread...
> >
> > Damien and Jarek, it seems the examples listed below both fit into a
> "citizen mappers coalescing on a local/regional way to do things" as well
> as a "somebody unfamiliar with Canadian transport mapping w.r.t. naming,
> network and operator tag conventions" (maybe who reads our wikis, maybe who
> does OT queries...) can figure this out quickly and sensibly.  It's great
> to see that's where things have landed, pretty close to a
> sweet-spot/bullseye.
> >
> > However (if I have to "spoil" a good thing, oh, well, this is a
> discussion forum...) I do think that operator=RATP is a bit curt even as
> "tout le monde à Paris sait ce que signifie la RATP."  (I recall being
> asked in a Regional Transportation Commission meeting what AASHTO stood for
> and I got it wrong, but then quickly got it right on the next try seconds
> later, alas, "too late").  It is true that an OSM convention is name=Saint
> Louis instead of name=St. Louis; abbreviations are frowned upon in
> databases like OSM because they are "one-way in the wrong way."  Please let
> us not allow perfection to become the enemy of the very good or even
> excellent and well-thought out and discussed, as are developing
> public_transport OSM data in Canada.  We're making a great map.
> >
> > Thank you again for spirited and interesting discussion.
> >
> > SteveA
> > California
> >
> >
> > > On Jul 16, 2018, at 6:06 PM, Damien Riegel 
> wrote:
> > >
> > > On 12 July 2018 at 17:17, OSM Volunteer stevea <
> stevea...@softworkers.com> wrote:
> > > On Jul 12, 2018, at 1:46 PM, Jarek Piórkowski 
> wrote:
> > > > Damien's question appears to be about nodes like
> > > > https://www.openstreetmap.org/node/438843513, which has
> > > > name=Berri-UQAM, operator=Société de transport de Montréal.
> > > > short_name=STM seems inappropriate here, we could do
> > > > operator:short_name=STM or something but it seems a bit much.
> > >
> > > Thank you for your analysis and reporting to the list, Jarek!  Yes, I
> agree that operator:short_name=STM is a bit of "overkill" (getting
> over-specific on the key side).
> > >
> > > > The nearby station https://www.openstreetmap.org/node/26233453 has
> > > > name=Jean-Drapeau, network=STM, operator=Société de transport de
> > > > Montréal which seems like an attempt as good as we might get.
> Commuter
> > > > rail station https://www.openstreetmap.org/node/548900549 has
> > > > network=RTM, operator=Réseau de transport métropolitain which fits
> > > > that scheme as well. Similar with a random bus line on North Shore
> > > > 

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

[deuzeffe]

On 12/08/2018 23:38, marc marc wrote:


sauf à supposer que tout les panneaux du pays ont été changé.


C'est le cas (sauf exceptions ou oublis qui confirment la règle) : tous 
les panneaux 90 où la limite a changé au 01/07 en 80 ont été changés en 
panneaux 80. Et pour bien rappeler que 3 voies, c'est 90, des panneaux 
90 ont été ajoutés. Plus le retour à 80 après les 3 voies. Plus...


Bref, la nuit du 30 juin au 1er juillet a été très courte pour les 
agents des DIR...


--
deuzeffe

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

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[OSM Volunteer stevea]

John, especially in light that we both volunteer in a wonderful organization 
like OSM, I consider neither of us poor.  Truly, I mean that.

It wouldn't be "confused" that I might be.  It would be much more leaning 
towards, if not firmly in, the camp of "abbreviating in OSM key:value pairs is 
frowned upon because it maps backwards incompletely."  That is a fair 
logical/mathematical/linguistic/database point.  Getting line-renderers to pay 
attention to short_name or alt_name or local_name or coalesce on something 
sensible, sure, that's a happy place.  I'd love to see a transport renderer 
that is wicked-smart with v2 and even v3 savvy colors, naming, routes and a 
"visual pop" that a good map does simply as you look at it.  That starts with 
good tagging including good discussion about tagging.  Simple as walking.

Politics aside and whether hordes flee JDT or not, I am talking about good 
tagging in OSM as transport networks and how they are named and "get smart" 
really is happening all over Earth.  Good protocols to "we're all paying 
attention together" works.  Whether ISO/UN/IEEE or other acronyms and how a 
committee really can get the phones to connect and the trains running on time, 
the ideas behind "let's agree on good language and tagging..." work, this is 
simply being good neighbors.  A big human family sharing a map acts like a big 
human family sharing a map.  We seem to continue to do that here in talk-ca, 
talk-us and so on.  Thank you.

SteveA
California

> On Aug 12, 2018, at 2:17 PM, john whelan  wrote:
> 
> Good heavens you mean we should spell out OCtranspo as Ottawa Carleton 
> Transpo in case any American tourists get confused?
> 
> Unfortunately the locals will probably get confused with this and whilst we 
> should cater to these foreign tourists I think what is on the signs locally 
> will be less confusing to the locals unless of course we get many more people 
> streaming in to escape Donald.
> 
> Or have I misunderstood some poor American?
> 
> Cheerio John
> 
> On Sun, 12 Aug 2018, 4:48 pm OSM Volunteer stevea, 
>  wrote:
> Dusting off a month-old thread...
> 
> Damien and Jarek, it seems the examples listed below both fit into a "citizen 
> mappers coalescing on a local/regional way to do things" as well as a 
> "somebody unfamiliar with Canadian transport mapping w.r.t. naming, network 
> and operator tag conventions" (maybe who reads our wikis, maybe who does OT 
> queries...) can figure this out quickly and sensibly.  It's great to see 
> that's where things have landed, pretty close to a sweet-spot/bullseye.
> 
> However (if I have to "spoil" a good thing, oh, well, this is a discussion 
> forum...) I do think that operator=RATP is a bit curt even as "tout le monde 
> à Paris sait ce que signifie la RATP."  (I recall being asked in a Regional 
> Transportation Commission meeting what AASHTO stood for and I got it wrong, 
> but then quickly got it right on the next try seconds later, alas, "too 
> late").  It is true that an OSM convention is name=Saint Louis instead of 
> name=St. Louis; abbreviations are frowned upon in databases like OSM because 
> they are "one-way in the wrong way."  Please let us not allow perfection to 
> become the enemy of the very good or even excellent and well-thought out and 
> discussed, as are developing public_transport OSM data in Canada.  We're 
> making a great map.
> 
> Thank you again for spirited and interesting discussion.
> 
> SteveA
> California
> 
> 
> > On Jul 16, 2018, at 6:06 PM, Damien Riegel  wrote:
> > 
> > On 12 July 2018 at 17:17, OSM Volunteer stevea  
> > wrote:
> > On Jul 12, 2018, at 1:46 PM, Jarek Piórkowski  wrote:
> > > Damien's question appears to be about nodes like
> > > https://www.openstreetmap.org/node/438843513, which has
> > > name=Berri-UQAM, operator=Société de transport de Montréal.
> > > short_name=STM seems inappropriate here, we could do
> > > operator:short_name=STM or something but it seems a bit much.
> > 
> > Thank you for your analysis and reporting to the list, Jarek!  Yes, I agree 
> > that operator:short_name=STM is a bit of "overkill" (getting over-specific 
> > on the key side).
> > 
> > > The nearby station https://www.openstreetmap.org/node/26233453 has
> > > name=Jean-Drapeau, network=STM, operator=Société de transport de
> > > Montréal which seems like an attempt as good as we might get. Commuter
> > > rail station https://www.openstreetmap.org/node/548900549 has
> > > network=RTM, operator=Réseau de transport métropolitain which fits
> > > that scheme as well. Similar with a random bus line on North Shore
> > > https://www.openstreetmap.org/relation/3472432
> > 
> 
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca


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

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

[marc marc]

Bonsoir,


Le 12. 08. 18 à 23:21, 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

> on trouve des panneaux 80.

vu qu'il y a un panneau, je mettrait sign
parce que si demain une loi passe pour changer la vitesse par défaut,
la limite restera tant que le panneau n'est pas changé ou supprimé.

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

Oui c'est un bon endroit à aller voir sur place ce qu'il en est.
A distance j'ai du mal à voir comment on pourrait prédire s'il y a
toujours un panneau 90 ou pas.

>> Reste que des maxspeed=90 source:maxspeed=sign
> datant d'avant juillet 2018 n'ont pas lieu d'être.

je ne comprend pas ce que tu veux dire.
si le panneau 90 est tjs là, il s'applique non ?
sauf à supposer que tout les panneaux du pays ont été changé.

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]

J'oubliais une question subsidiaire : à la fin des sections à 90 il y a 
souvent des panneaux de fin de limitation (donc 80 avec 
source:maxspeed=FR:rural) mais par exemple après des sorties de voies 
expresses, on trouve des panneaux 80.


Dans ce cas je mets source:maxspeed=FR:rural et non source:maxspeed=sign 
car c'est la règlementation, le panneau n'est qu'une tautologie (utile 
dans le sens où après avoir fait 110 il est préférable de rappeler que 
maintenant c'est 80 et non 90 ou 110 mais non nécessaire puisque la 
voirie ne permet pas règlementairement de dépasser 80 km/h).


source:maxspeed=FR:rural me semple plus pratique pour les mises à jour.

Jean-Yvon


Le 12/08/2018 à 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.


Usuellement

maxspeed=80
source:maxspeed=FR:rural

est la bonne mise-à-jour. Y compris pour les voiries à au moins deux 
voies dans le même sens car par défaut c'est 80.


Dans certains cas :

lane:3
lane:forward=2
lane:backward=1
maxspeed:forward=90
maxspeed:backward=80
source:maxspeed:forward=sign
source:maxspeed:backward=FR:rural

lane:3
lane:forward=1
lane:backward=2
maxspeed:forward=80
maxspeed:backward=90
source:maxspeed:forward=FR:rural
source:maxspeed:backward=80

Plus rarement :

lane:2
oneway=yes
maxspeed=90
source:maxspeed=sign

Ou encore

lane:4
maxspeed=90
source:maxspeed=sign

Reste que des

maxspeed=90
source:maxspeed=sign

datant d'avant juillet 2018 n'ont pas lieu d'être. S'il n'y a pas deux 
voies dans le même sens, c'est simple (et


https://overpass-turbo.eu/s/AZw permet de trouver les cas plus trop 
logiques).


Attention : 2 voies dans le même sens - avec ou sans séparateur 
central - est une condition nécessaire mais pas suffisante il faut en 
plus un panneau - et que les voies aillent dans la même direction au 
sens de turn=through.
Par exemple un tronçon court restera sans doute à 80, une voie de 
dépassement repassera sans doute à 90 mais à vérifier sur le terrain. 
Éventuellement en posant une note/fixme et en précisant de ne pas 
utiliser des images datant d'avant juillet 2018.


Jean-Yvon



___
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-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[john whelan]

Good heavens you mean we should spell out OCtranspo as Ottawa Carleton
Transpo in case any American tourists get confused?

Unfortunately the locals will probably get confused with this and whilst we
should cater to these foreign tourists I think what is on the signs locally
will be less confusing to the locals unless of course we get many more
people streaming in to escape Donald.

Or have I misunderstood some poor American?

Cheerio John

On Sun, 12 Aug 2018, 4:48 pm OSM Volunteer stevea, <
stevea...@softworkers.com> wrote:

> Dusting off a month-old thread...
>
> Damien and Jarek, it seems the examples listed below both fit into a
> "citizen mappers coalescing on a local/regional way to do things" as well
> as a "somebody unfamiliar with Canadian transport mapping w.r.t. naming,
> network and operator tag conventions" (maybe who reads our wikis, maybe who
> does OT queries...) can figure this out quickly and sensibly.  It's great
> to see that's where things have landed, pretty close to a
> sweet-spot/bullseye.
>
> However (if I have to "spoil" a good thing, oh, well, this is a discussion
> forum...) I do think that operator=RATP is a bit curt even as "tout le
> monde à Paris sait ce que signifie la RATP."  (I recall being asked in a
> Regional Transportation Commission meeting what AASHTO stood for and I got
> it wrong, but then quickly got it right on the next try seconds later,
> alas, "too late").  It is true that an OSM convention is name=Saint Louis
> instead of name=St. Louis; abbreviations are frowned upon in databases like
> OSM because they are "one-way in the wrong way."  Please let us not allow
> perfection to become the enemy of the very good or even excellent and
> well-thought out and discussed, as are developing public_transport OSM data
> in Canada.  We're making a great map.
>
> Thank you again for spirited and interesting discussion.
>
> SteveA
> California
>
>
> > On Jul 16, 2018, at 6:06 PM, Damien Riegel 
> wrote:
> >
> > On 12 July 2018 at 17:17, OSM Volunteer stevea <
> stevea...@softworkers.com> wrote:
> > On Jul 12, 2018, at 1:46 PM, Jarek Piórkowski 
> wrote:
> > > Damien's question appears to be about nodes like
> > > https://www.openstreetmap.org/node/438843513, which has
> > > name=Berri-UQAM, operator=Société de transport de Montréal.
> > > short_name=STM seems inappropriate here, we could do
> > > operator:short_name=STM or something but it seems a bit much.
> >
> > Thank you for your analysis and reporting to the list, Jarek!  Yes, I
> agree that operator:short_name=STM is a bit of "overkill" (getting
> over-specific on the key side).
> >
> > > The nearby station https://www.openstreetmap.org/node/26233453 has
> > > name=Jean-Drapeau, network=STM, operator=Société de transport de
> > > Montréal which seems like an attempt as good as we might get. Commuter
> > > rail station https://www.openstreetmap.org/node/548900549 has
> > > network=RTM, operator=Réseau de transport métropolitain which fits
> > > that scheme as well. Similar with a random bus line on North Shore
> > > https://www.openstreetmap.org/relation/3472432
> >
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-cz] geograficke regiony v CR

[Jan Macura]

Ahoj,


2018-08-10 11:33 GMT+02:00 majka :

> Stejně jako u podobných záležitostí, že se zeptám? ;)
> Opravdu nečekám, že u všeho "on the ground" bude cedule s názvem, jinak by
> nám toho v mapě moc nezbylo...
>

2018-08-10 13:08 GMT+02:00 Pavel Machek :

> Jsem mistni tak to proste vim? Zeptam se mistnich jak se to tady jmenuje?
> :-).
>

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!"?

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

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

[osm . sanspourriel]

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.


Usuellement

maxspeed=80
source:maxspeed=FR:rural

est la bonne mise-à-jour. Y compris pour les voiries à au moins deux 
voies dans le même sens car par défaut c'est 80.


Dans certains cas :

lane:3
lane:forward=2
lane:backward=1
maxspeed:forward=90
maxspeed:backward=80
source:maxspeed:forward=sign
source:maxspeed:backward=FR:rural

lane:3
lane:forward=1
lane:backward=2
maxspeed:forward=80
maxspeed:backward=90
source:maxspeed:forward=FR:rural
source:maxspeed:backward=80

Plus rarement :

lane:2
oneway=yes
maxspeed=90
source:maxspeed=sign

Ou encore

lane:4
maxspeed=90
source:maxspeed=sign

Reste que des

maxspeed=90
source:maxspeed=sign

datant d'avant juillet 2018 n'ont pas lieu d'être. S'il n'y a pas deux 
voies dans le même sens, c'est simple (et


https://overpass-turbo.eu/s/AZw permet de trouver les cas plus trop 
logiques).


Attention : 2 voies dans le même sens - avec ou sans séparateur central 
- est une condition nécessaire mais pas suffisante il faut en plus un 
panneau - et que les voies aillent dans la même direction au sens de 
turn=through.
Par exemple un tronçon court restera sans doute à 80, une voie de 
dépassement repassera sans doute à 90 mais à vérifier sur le terrain. 
Éventuellement en posant une note/fixme et en précisant de ne pas 
utiliser des images datant d'avant juillet 2018.


Jean-Yvon

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

Re: [Talk-cz] geograficke regiony v CR

[Jan Macura]

Ahoj,

2018-08-10 11:25 GMT+02:00 Martin Ždila :

> Nie. Ani katastralne hranice alebo nazvy dolin ci vrcholov nie je mozne az
> na vynimky zistit "on the ground" a predsa do OSM patria.
>

No tak to je hodně špatný příměr. a) katastrální hranice jsou vyznačené v
terénu (myšleno hranice k.ú., které v OSM jsou; hranice parcel v OSM nejsou
(naštěstí)), b) názvy vrcholů zpravidla na místě označeny bývají, pokud ne
na místě, tak nějakou směrovkou, pokud ani to ne, lze je snadno zjistit
mezi místním obyvatelstvem. To bych si o geomorf. jednotkách rozhodně
tvrdit netroufal.

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

[OSM-talk-fr] audit des panneaux

[osm . sanspourriel]

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

Re: [Talk-ca] Montréal: Inconsistency in Public Transportation Provider's Name

[OSM Volunteer stevea]

Dusting off a month-old thread...

Damien and Jarek, it seems the examples listed below both fit into a "citizen 
mappers coalescing on a local/regional way to do things" as well as a "somebody 
unfamiliar with Canadian transport mapping w.r.t. naming, network and operator 
tag conventions" (maybe who reads our wikis, maybe who does OT queries...) can 
figure this out quickly and sensibly.  It's great to see that's where things 
have landed, pretty close to a sweet-spot/bullseye.

However (if I have to "spoil" a good thing, oh, well, this is a discussion 
forum...) I do think that operator=RATP is a bit curt even as "tout le monde à 
Paris sait ce que signifie la RATP."  (I recall being asked in a Regional 
Transportation Commission meeting what AASHTO stood for and I got it wrong, but 
then quickly got it right on the next try seconds later, alas, "too late").  It 
is true that an OSM convention is name=Saint Louis instead of name=St. Louis; 
abbreviations are frowned upon in databases like OSM because they are "one-way 
in the wrong way."  Please let us not allow perfection to become the enemy of 
the very good or even excellent and well-thought out and discussed, as are 
developing public_transport OSM data in Canada.  We're making a great map.

Thank you again for spirited and interesting discussion.

SteveA
California


> On Jul 16, 2018, at 6:06 PM, Damien Riegel  wrote:
> 
> On 12 July 2018 at 17:17, OSM Volunteer stevea  
> wrote:
> On Jul 12, 2018, at 1:46 PM, Jarek Piórkowski  wrote:
> > Damien's question appears to be about nodes like
> > https://www.openstreetmap.org/node/438843513, which has
> > name=Berri-UQAM, operator=Société de transport de Montréal.
> > short_name=STM seems inappropriate here, we could do
> > operator:short_name=STM or something but it seems a bit much.
> 
> Thank you for your analysis and reporting to the list, Jarek!  Yes, I agree 
> that operator:short_name=STM is a bit of "overkill" (getting over-specific on 
> the key side).
> 
> > The nearby station https://www.openstreetmap.org/node/26233453 has
> > name=Jean-Drapeau, network=STM, operator=Société de transport de
> > Montréal which seems like an attempt as good as we might get. Commuter
> > rail station https://www.openstreetmap.org/node/548900549 has
> > network=RTM, operator=Réseau de transport métropolitain which fits
> > that scheme as well. Similar with a random bus line on North Shore
> > https://www.openstreetmap.org/relation/3472432
> 


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

hebdoOSM Nº 420 2018-07-31-2018-08-06

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 420 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10586/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

hebdoOSM Nº 420 2018-07-31-2018-08-06

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 420 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10586/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

hebdoOSM Nº 420 2018-07-31-2018-08-06

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 420 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10586/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

hebdoOSM Nº 420 2018-07-31-2018-08-06

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 420 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10586/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.

Re: [Talk-us] State Open Data

[Kevin Kenny]

Went and sent this from the wrong return address - trying again.

On Sun, Aug 12, 2018 at 4:26 PM Kevin Kenny  wrote:
>
> On Sun, Aug 12, 2018 at 1:05 PM OSM Volunteer stevea
>  wrote:
> > I'm not an attorney, though were I to attempt to sharpen focus on these two 
> > replies, I'd say that in California, it's more like this:  data produced by 
> > state agencies (by our state government personnel "on the clock") 
> > publishing them as "produced by the state of California" cannot have 
> > onerous copyright terms/restrictions put upon them.  They simply "belong to 
> > the public."  (This is especially true of GIS data, as in the County of 
> > Santa Clara and Orange County/Sierra Club cases).
> >
> > So when you say "copyright...owned by the government," that is effectively 
> > equivalent to "copyright owned by the People of the state" because of 
> > California's Open Data laws and stare decisis (law determined by court 
> > precedence/findings).  Whether "public domain" is the correct legal term 
> > I'm not sure, but if there is a distinction between the legality of 
> > California-produced data and "the data are in the public domain" it is 
> > either very subtle or completely non-existent; I consider 
> > California-produced data "somewhere around, if not actually PD" and "fully 
> > ODbL-compatible" for OSM purposes.  So, (and I hope this dispels any 
> > confusion and answers your question, Pine), "created by the government" 
> > means they can't put "onerous copyright" on it, meaning it is effectively 
> > owned by the People for any purpose for which We see fit.
>
> 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.
>
> Of course, as people like Frederik Ramm are quick to point out, no
> imported data are truly safe! (In the US system, a deep-pocketed
> plaintiff can simply bankrupt the defendant before the conclusion of a
> civil suit, and the law is particularly murky in the
> copyright-friendly Second Circuit, which comprises New York, Vermont
> and Connecticut.)
>
> 
>
> I already sent Clifford Snow a reply in private email, but this
> deserves to be elaborated more in public, given how the conversation
> has turned.
>
> I am not a lawyer either, but as a scholar I have had to learn some of
> this stuff.
>
> I live in the Second Circuit, and the situation with respect to State
> and local government works is complicated here. The confusion stems
> from a decision rendered by the Second Circuit in the case of _Suffolk
> County v First American Real Estate Solutions_ (261 F. 3d 179 (2001):
> https://openjurist.org/261/f3d/179/county-v-first). First American was
> a real estate multiple listing service that had acquired Suffolk
> County's tax maps under New York's Freedom of Information Law, and was
> republishing them without license to its participating realtors.
> Suffolk County, motivated by the desire for cost recovery for the
> maintenance of the tax rolls, sued for copyright infringement. First
> American moved to dismiss, on the grounds that the Freedom of
> Information Law extinguished any copyright interest that Suffolk
> County might have had in the product. The district court initially
> denied the motion. On petition to reconsider, the district court
> agreed with First American that the Freedom of Information Law
> requires that Suffolk County may not use whatever copyright subsists
> in the tax maps to restrict their republication.
>
> The Second Circuit held that the Freedom of Information Law is fully
> satisfied as long as the public has the right to inspect the
> copyrighted records, and that FOIL does not extinguish the possibility
> of a copyright claim. Since it was ruling on a motion to dismiss,
> there was no ruling on the facts of the case, so the judicial opinion
> did not reach the argument of whether the maps had sufficient
> originality to survive a claim under the _Feist v Rural_ (499 U.S. 340
> (1991) - 
> https://en.wikipedia.org/wiki/Feist_Publications,_Inc.,_v._Rural_Telephone_Service_Co.)
> standard. Suffolk's initial argument appears to have been crafted to
> follow the 'sweat of the brow' standard. Nevertheless, the Second
> Circuit accepted that the originality claim was sufficiently pleaded.
> Nevertheless, the opinion recognized that 'items such as street
> location and landmarks were "physical facts"-and thus not protected
> elements" (_Suffolk_ at 24) and that in an earier case it had 'thus
> focused on "the overall manner in which [the plaintiff] selected,
> coordinated, and arranged the expressive 

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

[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

Re: [OSM-talk-fr] interruption coupure d'une piste cyclable

[Jérôme Seigneuret]

En effet mais bicycle dismount est valable pour tous les trottoirs et
passage piéton en soi... Chez nous vu le nombre de passage piéton n'ayant
pas de marquage de voie au sol ou de signalisation vélo aérienne pour moi
c'est implicite...  En clair, tu pousses ton vélo sinon tu reprends la
route.L'accès ça reste un highway=footway et implicitement bicycle=dismount
(cas valable pour les accès aux immeubles par la porte d'entrée).
Le non respect de cette disposition c'est 135€ d'amende...
Tu n'a pas le droit de rouler sur un trottoir (sauf zone piétonne, zone de
rencontre explicite) sans y avoir été explicitement invité ou forcé par la
signalisation.

dismount c'est ne pas dire no. Mais en soit si tu descends de ton vélo tu
n'es plus cycliste mais piéton donc c'est quoi le problème et quel est le
réel sens de cette clé dans la base vous me direz?!
Ben c'est simplement pour simplifier d'une part les traitement, d'autre par
parce que dans d'autre pays c'est signalé ainsi explicitement car il y a un
code plus dédié et orienter pour ce mode de circulation

En clair chez nous si tu mets no ou dismount tu devrais avoir un
itinéraire. Mais il faut encore que la distance piétonne ne soit pas trop
longue. (50m à pousser ton vélo ça risque de te gaver et tu préféreras
reprendre la route)

Chez nos amis anglais c'est aussi le cas mais en plus ils peuvent avoir un
marquage au sol ou/et un panneau aérien pour signaler cela:
"End of Route" avec un vélo dans un carré bleue et/ou "Cyclist Dismount"

J'ai pas vu de signalisation officielle en France pour cela.
Pour moi les références c'est http://www.securite-routiere.gouv.fr et
https://ffvelo.fr/

Cette charte présente des cas
https://ffvelo.fr/wp-content/uploads/2013/10/CHARTE-CYCLABLES-2016.pdf

Bien! Pas Bien! Maintenant, la base OSM doit aussi présenter les cas qui
sont ridicules et dangereux et non les simplifier car c'est plus simple
ainsi. Ainsi on pourra présenter les problèmes aux collectivités et
proposer des solutions d'améliorations afin d'avoir un vrai réseau vélo qui
ne nous met pas en danger ou nous force à le faire. Cela pose aussi des
problèmes de responsabilité civil ou pénal des communes pour la mise en
danger des usagers. Cas de piste mal matérialisé avec cohabitation piéton
et vélo,

Faites un audit des panneaux et marquage de votre commune et vous allez
bien rire jaune.

Bonne soirée,
Jérôme


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

> Le 11/08/2018 à 10:03, lenny.libre - lenny.li...@orange.fr a écrit :
>
> ou y a-t-il des attributs qui disent descendre de vélo
>
> Par hasard je suis tombé sur la page en allemand
>  qui répond à ta
> question et à ton cas précis (traversée d'une route sans pannonceau
> cedez-le-passage mais fin de piste - ils donne le cas d'une courte section
> réservée aux piétons) :
> bicycle=dismount
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] State Open Data

[OSM Volunteer stevea]

I'm not an attorney, though were I to attempt to sharpen focus on these two 
replies, I'd say that in California, it's more like this:  data produced by 
state agencies (by our state government personnel "on the clock") publishing 
them as "produced by the state of California" cannot have onerous copyright 
terms/restrictions put upon them.  They simply "belong to the public."  (This 
is especially true of GIS data, as in the County of Santa Clara and Orange 
County/Sierra Club cases).

So when you say "copyright...owned by the government," that is effectively 
equivalent to "copyright owned by the People of the state" because of 
California's Open Data laws and stare decisis (law determined by court 
precedence/findings).  Whether "public domain" is the correct legal term I'm 
not sure, but if there is a distinction between the legality of 
California-produced data and "the data are in the public domain" it is either 
very subtle or completely non-existent; I consider California-produced data 
"somewhere around, if not actually PD" and "fully ODbL-compatible" for OSM 
purposes.  So, (and I hope this dispels any confusion and answers your 
question, Pine), "created by the government" means they can't put "onerous 
copyright" on it, meaning it is effectively owned by the People for any purpose 
for which We see fit.

If there ARE lawyers out there who think I'm getting this wrong, please chime 
in, but I strongly believe this is firm legal ground.

FEDERAL laws are slightly different, and maybe even MORE generous:  data 
produced by federal agencies are "in the public domain" (unless classified as 
Confidential, Secret and Most Secret, which are NOT for wider consumption).

SteveA
California
(and again, not an attorney, though I am an educated person who can read and 
interpret my laws)


> From: Pine W 
> Subject: Re: [Talk-us] State Open Data
> Date: August 11, 2018 at 10:59:55 AM PDT
> To: talk-us 
> 
> I'm interested in this subject. An issue is that the copyright might be owned 
> by the government entity that created it, even if the records are open for 
> the public. If something is public record in California, does that also mean 
> that it's not copyrighted by the government entity that created it?
> 
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )


> On Sat, Aug 11, 2018 at 12:01 PM Pine W  wrote:
> I'm interested in this subject. An issue is that the copyright might be owned 
> by the government entity that created it, even if the records are open for 
> the public. If something is public record in California, does that also mean 
> that it's not copyrighted by the government entity that created it?
> 
> Its my understanding that if the state government has an open data law 
> similar to the US, then when they release the data it's public domain. There 
> are exceptions. Sometime they license the data from a company without have 
> the rights to release it as PD. They also have exceptions for not releasing 
> data that has personal information. I sat through a talk by WSDOT. One of the 
> big issues they pressed was to be very careful be for adding data to the 
> state's open data portal. Once it's out in the open, they can't get it back.



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

Re: [OSRM-talk] Updating a map

[Julien Coupey]

Hi Didier,

The exclude flag feature introduced a while back in OSRM might explain a 
change in RAM requirements for the same OSM file. If you don't need that 
feature, you can disable the associated extra work/memory usage by 
setting an empty "excludable" list in the profile at:


https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua#L122-L126

Hope that helps
Julien

On 10/08/2018 09:34, Didier Doumerc wrote:
I have only 12 GB of RAM but when I installed the previous file version, 
it was ok with only 4 GB or RAM.


Is there anyway way to successfully prepare the files ? Perhaps by 
downloading them ready yet ?


Thanks for your answer.

Didier

Le jeu.09/08/18 à 18:15, Sayer, Bryan a écrit :

When I had that problem it was due to lack of memory. For the United 
States, I had to have 64 GB of memory prepare, though I was doing it 
through a Stata interface, not directly.


*From:*Didier Doumerc mailto:doumer...@adimep.com>>
*Sent:*Thursday, August 9, 2018 11:53:39 AM
*To:*osrm-talk@openstreetmap.org 
*Subject:*[OSRM-talk] Updating a map
Hi,

I need help for updating the map file. Here is what I get when I run 
osrm-prepare france-latest.osrm. It stops at 90%


[info] Input file: france-latest.osrm
[info] Profile: profile.lua
[info] Threads: 8
[info] Loading edge-expanded graph representation
[info] Opening france-latest.osrm.ebg
[info] Reading 25874228 edges from the edge based graph
[info] Done reading edges
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0

merged 51783408 edges out of 103496912
contractor finished initalization
initializing elimination PQ ...ok
preprocessing 13952773 nodes  10% . 20% . 30% . 40% . 50% . 60% . 
[flush 9336408 nodes]  70% . 80% . 90% .




Before, I run osrm-extract france-latest/osm.pbf


[info] Input file: france-latest.osm.pbf
[info] Profile: profile.lua
[info] Threads: 8
[info] Using script profile.lua
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0

[info] Parsing in progress..
[info] input file generated by osmium/1.8.0
[info] timestamp: 2018-08-05T20:00:03Z
[info] Using turn restrictions
[info] Found 3 exceptions to turn restrictions:
[info]   motorcar
[info]   motor_vehicle
[info]   vehicle
[info] Parsing finished after 914.304 seconds
[info] Raw input contains 387758183 nodes, 57191546 ways, and 521319 
relations, and 0 unknown entities

[extractor] Sorting used nodes        ... ok, after 8.97724s
[extractor] Erasing duplicate nodes   ... ok, after 5.16838s
[extractor] Sorting all nodes         ... ok, after 270.95s
[extractor] Building node id map      ... ok, after 146.325s
[extractor] setting number of nodes   ... ok
[extractor] Confirming/Writing used nodes     ... ok, after 84.6342s
[info] Processed 36442184 nodes
[extractor] Sorting edges by start    ... ok, after 46.7546s
[extractor] Setting start coords      ... ok, after 188.624s
[extractor] Sorting edges by target   ... ok, after 47.2029s
[extractor] Computing edge weights    ... ok, after 201.467s
[extractor] Sorting edges by renumbered start ... ok, after 47.6069s
[extractor] Writing used egdes       ... ok, after 33.4863s
[extractor] setting number of edges   ... ok
[info] Processed 37971544 edges
[extractor] Sorting used ways         ... ok, after 3.42604s
[extractor] Sorting 34351 restriction. by from... ok, after 0.078667s
[extractor] Fixing restriction starts ... ok, after 1.32651s
[extractor] Sorting restrictions. by to  ... ok, after 0.048604s
[extractor] Fixing restriction ends   ... ok, after 1.28459s
[info] usable restrictions: 31935
[extractor] writing street name index ... ok, after 0.159635s
[info] extraction finished after 2046.13s
[info] Generating edge-expanded graph representation
[info]  - 31935 restrictions.
[info] Importing n = 36442184 nodes
[info]  - 17000 bollard nodes, 41647 traffic lights
[info]  and 37971544 edges
[info] Graph loaded ok and has 37971544 edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Node compression ratio: 0.166043
[info] Edge compression ratio: 0.19941
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 nodes in edge-expanded graph
[info] generating edge-expanded edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 edge based nodes
[info] Node-based graph contains 13952773 edges
[info] Edge-expanded graph ...
[info]   contains 25874228 edges
[info]   skips 26910 turns, defined by 

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

[Martin Koppenhoefer]

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.

Gruß,
Martin 

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

[Talk-cz] Pozvánka na srpnový pražský mapathon Missing Maps

[Pavel PETR]

Zveme Vás na další pravidelný humanitární mapathon v Praze, který proběhne
v úterý 28. 8. od 18:00 v coworku OPERO (Salvátorská 8, Praha 1).
Registrace:
https://www.eventbrite.co.uk/e/srpnovy-missing-maps-mapathon-v-praze-v-coworkingu-opero-registration-49007832747

-- 
Pavel PETR
3D scanning technician @g4d.cz 
tweeting @pointcloudfever 
___
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

[chris66]

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


C.



___
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

[chris66]

Am 08.08.2018 um 18:16 schrieb Florian Lohoff:


entlang des
Datteln-Weser-Kanals sind das tracks.


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
tracktype=grade2 (Asphalt hier sehr selten)
surface=compacted
foot=permissive
bicycle=permissive
horse=no (teilweise)
motor_vehicle=no
operator=WSV

Grüße
Chris



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

Re: [OSM-talk-fr] interruption coupure d'une piste cyclable

[osm . sanspourriel]

Le 11/08/2018 à 10:03, lenny.libre - lenny.li...@orange.fr a écrit :


ou y a-t-il des attributs qui disent descendre de vélo
Par hasard je suis tombé sur la page en allemand 
 qui répond à ta 
question et à ton cas précis (traversée d'une route sans pannonceau 
cedez-le-passage mais fin de piste - ils donne le cas d'une courte 
section réservée aux piétons) :

bicycle=dismount
___
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 Sat, Aug 11, 2018 at 12:36:25AM +0200, Andreas Meier wrote:
> Ich könnte sowohl mit Track oder Service gut leben, aber aus den bisherigen
> Argumenten leitet sich ggf. eine Empfehlung ab:
> > Die Abgrenzung track zu service: letzteres ist es dann, wenn es keiner
> > höheren Klasse angehört und wo hinführt, sonst track. 

Auch das ist umstritten. Für mich gehört service nicht zu den
Straßenklassen. Und die defintion im Wiki sagt auch das es sich 
eher um Wege auf Firmengeländen etc d.h. keine öffentlichen Wege 
handelt.

> Das finde ich eine sehr schön einfache und praktikable Definition, die ich
> bisher so nicht vor Augen hatte.

> Wenn man weiß (woher auch immer), dass der WSV die Wege unterhält, um die
> Wasserstraße zu kontrollieren, dann führen die Wege ja ausdrücklich „wo“
> hin. Das Ziel ist einfach kein Punktobjekt, sondern eine ausgedehnte
> Strecke. Damit wäre „highway = service“ meines Erachtens sowohl vom
> Bauchgefühl als auch im Sinne der Definition gerechtfertigt.

Für micht ist es das weil das eben ein Privatweg der WSV ist auf dem
der öffentlichkeit das Begehen und Befahren mit dem Fahrrad erlaubt ist.

> Damit käme es aber vor allem auf die Abgrenzung ab, welche Wege (inkl.
> Zu-/Verbindungswege?) gehören genau zur WSV oder einer entsprechenden
> Organisation. Ist das erkennbar oder wird das Service-Netz dann
> bruchstückhaft?

Ich denke ab den jeweiligen zufahrtsbeschränkungen d.h. Schranken etc.

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-dk] Konstruktioner i vand

[Michael Andersen]

søndag den 12. august 2018 13.19.18 CEST skrev Troels Arvin:
> Hej,
> 
> osm at workmail.com skrev:
> > Det er f.eks brugt ved Egholmfærgen (Ålborg). Så hvorfor ikke.
> 
> Tak. Jeg kan se, at dolphin-tagged elementer ved Aalborg ikke renderes på
> https://www.openstreetmap.org/#map=18/57.05909/9.88203
> 
> - og ej heller i København, efter at jeg har benyttet barrier=dolphin:
> https://www.openstreetmap.org/#map=19/55.64316/12.55288
> 
> Jeg har oprettet en Github issue om det:
> https://github.com/gravitystorm/openstreetmap-carto/issues/3339
> Jeg håber dét er det rette sted at henvende sig.

Det er det helt rette sted at henvende sig. Bemærk dog at masser af tags ikke 
renderes på OSM Carto (vores "standard" kort) og at det er et voldsomt 
komplekst projekt med mange hensyn at tage (og så vidt jeg forstår noget 
underbemandet).

Bemærk også at seamark:type=* tags primært bruges på https://
wiki.openstreetmap.org/wiki/OpenSeaMap projektet: http://map.openseamap.org/?
zoom=17=57.05996=9.88004=BFTFFTF0TF og at man nok 
derfor ikke kan forvente at disse også renderes på OSM Carto



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

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

[Harald Hartmann]

Nochmals: ich bezog mich nur auf die node_tags, way_tags und
relation_tags Tabellen! Die Position wird ja nur in nodes gespeichert
und hat einen eigenen timestamp. Und da die node_tags über node_id und
version mit nodes verbunden ist, würde ich eben die version beibehalten,
aber eben den (noch zu erstellenden) timestamp in node_tags updaten,
weil ich ja z.B. nur den opening_hours Tag kontrolliert und bestätigt habe.

Am 12.08.2018 um 13:29 schrieb Martin Koppenhoefer:
> Stell dir vor, jemand schiebt einen node mit barrier=gate opening_hours=x am 
> 1.1. und jemand anderes verifiziert den Node am 1.5. und das Datum wird 
> aktualisiert ohne die Version zu ändern. Dann sieht es in den Daten so aus 
> als hätte der Node erst am 1.5. seine Position geändert. 



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

Re: [Talk-cz] zajímavé přiřazení dle ulic

[Petr Vozdecký]

ad zastávka Kuldova
- nevim sice, zda to je ci neni chyba, ale pokud neni, pak to je IMHO kouzlo
nechteneho. Historicky vznikla drive zastavka TRAMvaje Kuldova, ta je primo
u krizeni Bubenickova/Kuldova. No a noveji zrizena blizka zastavka BUSu se
spise z technickych ci z pohledu dopravniho podniku praktickych duvodu
jmenuje stejne. Byt je 100 m daleko a za zeleznicnim mostem (a naspem).
Obdobne mozno nalezt v Brne sadu zastavek TRAMvaje Malinovskeho namesti. 
Jsou to 4 (v realu 5, ale 1 je v nepouzivanem smeru) zastavky, resp.
oznacniky a nastupiste, jmenuji se stejne a nejvzdalenejsi jsou od sebe 
mozna az 200 m (zast 1 smer Reckovice a zast 9 na Lesnou "u Tuzexu").

vop

-- Původní zpráva --
Od: Marián Kyral
Datum: 12. 8. 2018 v 11:19:31
Předmět: Re: [Talk-cz] zajímavé přiřazení dle ulic



Ahoj,

Dne 12.8.2018 v 10:48 Ladislav Nesnera napsal(a):

" Zaujala mě přiřazení
(https://www.openstreetmap.org/?mlat=49.20294=16.63700#map=17/49.20294/16.63700)
dle ulic, která jsou asi dobře, jen mi přijdou divná:

   * Kauflandu byla přiřčena ulice Bubeníčkova

"
Tady záleží kterým směrem je vchod. Předpokládám, že u parkoviště, tedy
nejbližší ulice je Bubeníčkova. Takže by to mělo být OK.

"

   * zastávce u přilehlého parkoviště Kuldova (vysoký žel. násep mezi je
   vtipný)

"
Zastávka občas bývají pojmenovány podle významnější ulice kterou křižují. V
Ostravě taky není zastávka Stodolní přímo na Stodolní, ale na Nádražní
kousek od začátku Stodolní.

"
Co už asi dobře nebude je ulice Lazaretní uvnitř areálu Zbrojovky, ale
zkontrolovat to neumím :-/
"
On celý ten areál asi má adresu Lazaretní. Podle mě je tam to pojmenování
navíc, ale na druhou stranu asi moc neškodí.
Oficiální vedení ulic z RUIANu se dá zobrazit jako vrstva na osmap.cz:
https://openstreetmap.cz/?zoom=17#map=17/49.20432/16.63538=d2
(https://openstreetmap.cz/?zoom=17#map=17/49.20432/16.63538=d2)

Marián

"
Létu zdar a Annu(https://cs.wikipedia.org/wiki/Anna#Pranostiky) vyzývám, aby
se konečně přestala flákat   ;?


"



___ 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-de] Datum einer Kontrolle vermerken?

[Martin Koppenhoefer]

sent from a phone

On 12. Aug 2018, at 11:19, Harald Hartmann  
wrote:

>> d.h. neue Version, die gleich ist wie die vorherige, oder?
> 
> 
> nicht zwingend, da sich ja nichts geändert hat, würde ich persönlich die
> Version(snummer) belassen und nur das Datum ändern. ... klar, dass
> könnte von einigen klar als Bruch in der Versionierung gesehen werden.



das Problem ist, damit fälscht man ja die DB (oder würde man sich das alte 
Datum auch merken?). Stell dir vor, jemand schiebt einen node mit barrier=gate 
opening_hours=x am 1.1. und jemand anderes verifiziert den Node am 1.5. und das 
Datum wird aktualisiert ohne die Version zu ändern. Dann sieht es in den Daten 
so aus als hätte der Node erst am 1.5. seine Position geändert. 

Man könnte erstmal eine neue Version für die erste Überprüfung erstellen, und 
wenn sich dann nichts ändert könnte man bei der zweiten Überprüfung nur das 
Datum ändern.
Oder man erstellt für reine Überprüfungen eine andere Art von Version, weil es 
sowieso besser wäre, man könnte bei Bedarf die alten Überprüfungen (wo es schon 
eine neuere Prüfung gibt) ignorieren, geändert hat sich ja nichts.

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

Re: [Talk-dk] Konstruktioner i vand

[Troels Arvin]

Hej,

osm at workmail.com skrev:
> Det er f.eks brugt ved Egholmfærgen (Ålborg). Så hvorfor ikke.

Tak. Jeg kan se, at dolphin-tagged elementer ved Aalborg ikke renderes på
https://www.openstreetmap.org/#map=18/57.05909/9.88203

- og ej heller i København, efter at jeg har benyttet barrier=dolphin:
https://www.openstreetmap.org/#map=19/55.64316/12.55288

Jeg har oprettet en Github issue om det:
https://github.com/gravitystorm/openstreetmap-carto/issues/3339
Jeg håber dét er det rette sted at henvende sig.

-- 
Troels


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

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

[Markus]

Hallo Harald,

> Diese ganzen Extra Tags um ein Datum für eine Wertänderung anzugeben
> braucht es eigentlich überhaupt nicht ... und bläht die Datenbank in der
> Tat unnötigerweise auf.

Wenn es bessere Wege gibt gern :-)

> Was es braucht, ist entweder eine Datenbankänderung, oder eine
> Anwendung, die das letzte Datum ermittelt.
> 
> 1. Datenbankänderung: eigentlich müsste ja nur in den Tabellen
> node/way/relation_tags [1] nur noch ein Feld timestamp hinzu, oder
> 
> 2. eine Anwendung mit Full History ermittelt eben die Diffs zwischen den
> Versionen und liefert das entsprechende Datum.

Hm - ein "Zeitstempel für jeden Speichervorgang"
ersetzt m.E. nicht das, was gemeint ist mit:
"letzte vollständige Überprüfung aller tags eines Objektes".

Und es ersetzt schon gar nicht die Bestätigung einer spezifischen
Qualitätskontrolle für ein genau beschriebenes Merkmal eines Objektes.

Klar vergrössert Qualitätskontrolle die Datenmenge.
Aber bestätigte positive Prüfung von Daten finde ich per se wertvoll :-)

Mit herzlichem Gruss,
Markus

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

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

[Harald Hartmann]

>> 1. Variante mit der Datenbankänderung auch via API die Möglichkeit, den
>> timestamp bewusst für ein Tag "up-to-date" zu setzen, wenn man es
>> einfach nur kontrolliert/gechecked hat.
> 
> 
> d.h. neue Version, die gleich ist wie die vorherige, oder?

nicht zwingend, da sich ja nichts geändert hat, würde ich persönlich die
Version(snummer) belassen und nur das Datum ändern. ... klar, dass
könnte von einigen klar als Bruch in der Versionierung gesehen werden.
Aber ich denke es wäre trotzdem ein besserer Schritt, als der, der jetzt
mit diesen Wildwuchs-Tags gegangen wird.



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

Re: [Talk-cz] zajímavé přiřazení dle ulic

[Marián Kyral]

Ahoj,

Dne 12.8.2018 v 10:48 Ladislav Nesnera napsal(a):
> Zaujala mě přiřazení
> 
> dle ulic, která jsou asi dobře, jen mi přijdou divná:
>
>   * Kauflandu byla přiřčena ulice Bubeníčkova
>

Tady záleží kterým směrem je vchod. Předpokládám, že u parkoviště, tedy
nejbližší ulice je Bubeníčkova. Takže by to mělo být OK.

>   * zastávce u přilehlého parkoviště Kuldova (vysoký žel. násep mezi
> je vtipný)
>

Zastávka občas bývají pojmenovány podle významnější ulice kterou
křižují. V Ostravě taky není zastávka Stodolní přímo na Stodolní, ale na
Nádražní kousek od začátku Stodolní.

> Co už asi dobře nebude je ulice Lazaretní uvnitř areálu Zbrojovky, ale
> zkontrolovat to neumím :-/
>

On celý ten areál asi má adresu Lazaretní. Podle mě je tam to
pojmenování navíc, ale na druhou stranu asi moc neškodí.
Oficiální vedení ulic z RUIANu se dá zobrazit jako vrstva na osmap.cz:
https://openstreetmap.cz/?zoom=17#map=17/49.20432/16.63538=d2

Marián

> Létu zdar a Annu 
> vyzývám, aby se konečně přestala flákat   ;?
>
>

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

[Martin Koppenhoefer]

sent from a phone

> On 12. Aug 2018, at 10:47, Harald Hartmann  
> wrote:
> 
> 1. Variante mit der Datenbankänderung auch via API die Möglichkeit, den
> timestamp bewusst für ein Tag "up-to-date" zu setzen, wenn man es
> einfach nur kontrolliert/gechecked hat.


d.h. neue Version, die gleich ist wie die vorherige, oder?

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

[Talk-cz] zajímavé přiřazení dle ulic

[Ladislav Nesnera]

Zaujala mě přiřazení

dle ulic, která jsou asi dobře, jen mi přijdou divná:

  * Kauflandu byla přiřčena ulice Bubeníčkova
  * zastávce u přilehlého parkoviště Kuldova (vysoký žel. násep mezi je
vtipný)

Co už asi dobře nebude je ulice Lazaretní uvnitř areálu Zbrojovky, ale
zkontrolovat to neumím :-/

Létu zdar a Annu 
vyzývám, aby se konečně přestala flákat   ;?



signature.asc
Description: OpenPGP digital signature
___
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?

[Harald Hartmann]

in der letzten Mail ganz vergessen: natürlich bräuchte man dann bei der
1. Variante mit der Datenbankänderung auch via API die Möglichkeit, den
timestamp bewusst für ein Tag "up-to-date" zu setzen, wenn man es
einfach nur kontrolliert/gechecked hat.

Die 2. Variante (ermittlung des letzten Datums) würde ja leider nur das
letzte Änderungsdatum ausspucken.



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

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

[Harald Hartmann]

Diese ganzen Extra Tags um ein Datum für eine Wertänderung anzugeben
braucht es eigentlich überhaupt nicht ... und bläht die Datenbank in der
Tat unnötigerweise auf.

Was es braucht, ist entweder eine Datenbankänderung, oder eine
Anwendung, die das letzte Datum ermittelt.

1. Datenbankänderung: eigentlich müsste ja nur in den Tabellen
node/way/relation_tags [1] nur noch ein Feld timestamp hinzu, oder

2. eine Anwendung mit Full History ermittelt eben die Diffs zwischen den
Versionen und liefert das entsprechende Datum.

Bzgl. Datenbankänderung ist evtl. auch der Verweis [2] aus der aktuellen
Wochennotiz lesenswert.

[1] https://wiki.openstreetmap.org/wiki/File:OSM_DB_Schema_2016-12-13.svg
[2]
http://blog.openstreetmap.de/blog/2018/08/wochennotiz-nr-420/#wn420_18059




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

[talk-ph] (no subject)

[Eugene Alvin Villar]

Hello all,

I'm forwarding this message posted by the Grab OSM team. You can see the
referred document in the message on GitHub here:
https://github.com/GRABOSM/Grab-Data/issues/19#issuecomment-410603506

~Eugene


> Good Morning All,
>
> Firstly, we would like to sincerly thank Erwin and Rally for the detailed
> explanation on how to use offset database.
>
> A quick clarification of the objects we mentioned in our github issue
> page. Before we started to work on Metro Manila, a note was posted in PH
> facebook page in the intent to get help from local community on any specifc
> policies to be followed, offset distance to be maintained etc. Alvin from
> the community made a point that there was a significant contribution made
> by Kaart team in the same area, so, we wanted to evaluate the city and
> understand if we want to continue working on Metro Manila or not.
>
> Two categories of objects were mentioned in the page -
> - missing roads - way id or node id mentioned here are the ids of roads
> nearby to the missing roads.
> - classification gaps - example objects with incorrect classifications.
>
> Hence these objects posted in our github page are only examples of missing
> roads and classification gaps we found in the sample areas we investigated
> and does not comprise the entire work we intend to do in the city.
>
> As suggested by Erwin, to further clarify what do we mean by
> classification gaps we tried to explain a handful of instances so that we
> can explain our project to the community better.
>
> Here is the document with examples.
>
> Local mappers have been of great help and support and we will ensure to
> continue producing high quality maps within our scope.
>
> Thanks
> Lavanya
> Grab Team
>
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [Talk-dk] Konstruktioner i vand

[osm]

Det er f.eks brugt ved Egholmfærgen (Ålborg). Så hvorfor ikke.

> 
> Tak, det ser ud til, at "dophin" ville være det helt korrekte til de 
> konstruktioner, som her drøftes. Imidlertid er det tilsyneladende ikke et 
> officielt tag, på trods af, at det benyttes en del: https://
> taginfo.openstreetmap.org/tags/man_made=dolphin
> 
> Når det benyttes næsten ni tusinde andre steder, tænker jeg, at det er OK 
> at anvende, eller?

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

Re: [Talk-dk] Konstruktioner i vand

[Michael Andersen]

søndag den 12. august 2018 09.06.17 CEST skrev Troels Arvin:
> Hej,
> 
> > Se her: https://en.wikipedia.org/wiki/Dolphin_(structure)
> 
> Tak, det ser ud til, at "dophin" ville være det helt korrekte til de
> konstruktioner, som her drøftes. Imidlertid er det tilsyneladende ikke et
> officielt tag, på trods af, at det benyttes en del: https://
> taginfo.openstreetmap.org/tags/man_made=dolphin
> 
> Når det benyttes næsten ni tusinde andre steder, tænker jeg, at det er OK
> at anvende, eller?

Der er i princippet ikke nogen "officielle" tags i OSM. I princippet kan hver 
enkelt mapper opfinde og anvende præcist de tags han lyster (og derfor ses der 
i mange tilfælde flere konkurrerende tags for de samme ting). I praksis har vi 
dog alle en interesse i at tingene så vidt muligt spiller sammen og at ting 
repræsenteres fornuftigt i de mest populære rendere, at vi kan få fornuftige 
resultater ved søgninger i vores data og at de forskellige OSM baserede 
routere har mulighed for at fungere fornuftigt.

Når man_made=dolphin er oppe på næsten 9000 anvendelser, så er det fordi det 
trods alt er relativt populært og dermed absolut OK at bruge. Det må også være 
på tide at få det ordentlig dokumenteret på wikien ;-)




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

Re: [Talk-dk] Konstruktioner i vand

[Troels Arvin]

Hej,

> Se her: https://en.wikipedia.org/wiki/Dolphin_(structure)

Tak, det ser ud til, at "dophin" ville være det helt korrekte til de 
konstruktioner, som her drøftes. Imidlertid er det tilsyneladende ikke et 
officielt tag, på trods af, at det benyttes en del: https://
taginfo.openstreetmap.org/tags/man_made=dolphin

Når det benyttes næsten ni tusinde andre steder, tænker jeg, at det er OK 
at anvende, eller?

-- 
Troels


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