Re: [Talk-cz] ruční GPS navigace

[Petr Schönmann]

Přes kabel by to mělo jít v režimu prenosu Garmin či ještě tam snad bude
nmea. Přes BT spíš ne. Zkus kdyztak napsat na podpora.garmin.cz

Dne st 18. 4. 2018 22:51 uživatel Miroslav Suchý  napsal:

> Dne 5.2.2018 v 13:43 xkomc...@centrum.cz napsal(a):
> > Kdyby tě zajímaly nějaké podrobnosti ohledně toho Oregonu, tak napiš
> > klidně i soukromě, co vím, povím ;-)
>
> Tak jsem nakonec skoncil u Garmin Oregon 700 a uz se tesim az to vyzkousim.
>
> Mam jeden dotaz: Da se ten Garmin nejak propojit s Android telefonem,
> tak aby telefon pouzival tu GPSku z Garmina? Nainstaloval jsem si GPS
> Bluetooth aplikaci, spojil telefon s Garminem pres bluetooth, zapnul
> jsem si developer setting a nastavil GPS Bluetooth aplikaci jako mock
> GPS, ale kdyz dam v GPS Bluetooth pripojeni na Garmin (ktereho vydi),
> tak se mu nedari pripojit.
>
> Je to marna snaha? Nebo to jde a mam vytrvat?
> Kdyz to nepujde, tak to nevadi. Jenom zkousim kde jsou hranice
> technologie :)
>
> Mirek
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-us] Gravel roads and surface tags in the US

[Harald Kliems]

I think compacted is definitely the best way to tag, but I agree with
Toby's point that common terms conflicting with OSM terminology is going to
lead to lots of errors. Looking at my own edits, I have mistakenly used
surface=gravel quite frequently. Not really sure what to do -- a "did you
really mean to tag 'surface=gravel'?" error message/tooltip in the editor?
I think actual gravel in the sense of the wiki is quite rare.

 Harald.

On Wed, Apr 18, 2018 at 6:38 PM Jack Burke  wrote:

> I've been tagging roads like that as compacted, once I learned more about
> the surfacing tech.
>
>
> -jack
>
> --
> Typos courtesy of fancy auto spell technology
>
> On April 18, 2018 6:19:07 PM EDT, Toby Murray 
> wrote:
>
>> I recently bought a gravel bicycle to ride on the many gravel roads in
>> Kansas. Like this one:
>> https://www.mapillary.com/app/?pKey=nYO4JI46L0SWzNAQlLT4kA=photo
>>
>> First question: What would you call this road? Obviously I am calling
>> it a "gravel road" but a couple of people have said they would call it
>> a "dirt road" so I'm curious if there are any other common terms to
>> describe this type of road in different regions of the US.
>>
>> Second question: How would you tag this road? There is a
>> surface=gravel tag that is in pretty common usage in Kansas and
>> neighboring states. However looking at the wiki page for the surface
>> tag[1], this is not wiki-correct. According to that page
>> surface=gravel is to be used for large rocks (4-8cm) that are laid
>> down loosely like those typically used as ballast on railroad beds. I
>> believe The Mapillary picture I linked to would be considered
>> surface=compacted according to the wiki because the rocks are much
>> smaller and the surface is stabilized with a binding agent. There is a
>> big difference between the two when it comes to bicycle riding.
>> Railroad ballast is bone jarring and flat tire inducing whereas gravel
>> roads are pretty manageable on the right kind of bike.
>>
>> But If you call something a "gravel road" and there is a "gravel"
>> option in the editor preset for the surface tag, people are going to
>> choose the gravel option and not look for "compacted" since that is
>> not a common term here. I assume it is a more common term in the UK
>> and that is why it is used in OSM.
>>
>> And lastly there are trails that are surfaced with a similar material
>> but crushed to a smaller size like here:
>> https://www.mapillary.com/app/?pKey=iQNqP-dfQ-Rm6AD9REMsgQ=photo
>>
>> I'm trying to decide if that is better as surface=compacted or
>> surface=fine_gravel although fine_gravel seems to be a slightly
>> different process from what I see on the wiki.
>>
>> Maybe this should be directed at the tagging list but I thought I
>> would get thoughts from the US community since we seem to be the ones
>> using the tag incorrectly (according to the wiki)
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:surface
>>
>> Toby
>>
>> --
>>
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Gravel roads and surface tags in the US

[Dave Swarthout]

This topic gets revisited from time to time and as you'll see, opinions
differ about how to tag these surfaces. For your example, I would tag it as
surface=gravel and tracktype=grade1. You can also include a smoothness=*
tag to further characterize its drivability.

I have never seen a highway for automotive or truck use that used railroad
ballast for a surface. And if I did, I would avoid driving on it at all
costs.

On Wed, Apr 18, 2018 at 4:36 PM, Jack Burke  wrote:

> I've been tagging roads like that as compacted, once I learned more about
> the surfacing tech.
>
> -jack
>
> --
> Typos courtesy of fancy auto spell technology
>
> On April 18, 2018 6:19:07 PM EDT, Toby Murray 
> wrote:
>
>> I recently bought a gravel bicycle to ride on the many gravel roads in
>> Kansas. Like this one:
>> https://www.mapillary.com/app/?pKey=nYO4JI46L0SWzNAQlLT4kA=photo
>>
>> First question: What would you call this road? Obviously I am calling
>> it a "gravel road" but a couple of people have said they would call it
>> a "dirt road" so I'm curious if there are any other common terms to
>> describe this type of road in different regions of the US.
>>
>> Second question: How would you tag this road? There is a
>> surface=gravel tag that is in pretty common usage in Kansas and
>> neighboring states. However looking at the wiki page for the surface
>> tag[1], this is not wiki-correct. According to that page
>> surface=gravel is to be used for large rocks (4-8cm) that are laid
>> down loosely like those typically used as ballast on railroad beds. I
>> believe The Mapillary picture I linked to would be considered
>> surface=compacted according to the wiki because the rocks are much
>> smaller and the surface is stabilized with a binding agent. There is a
>> big difference between the two when it comes to bicycle riding.
>> Railroad ballast is bone jarring and flat tire inducing whereas gravel
>> roads are pretty manageable on the right kind of bike.
>>
>> But If you call something a "gravel road" and there is a "gravel"
>> option in the editor preset for the surface tag, people are going to
>> choose the gravel option and not look for "compacted" since that is
>> not a common term here. I assume it is a more common term in the UK
>> and that is why it is used in OSM.
>>
>> And lastly there are trails that are surfaced with a similar material
>> but crushed to a smaller size like here:
>> https://www.mapillary.com/app/?pKey=iQNqP-dfQ-Rm6AD9REMsgQ=photo
>>
>> I'm trying to decide if that is better as surface=compacted or
>> surface=fine_gravel although fine_gravel seems to be a slightly
>> different process from what I see on the wiki.
>>
>> Maybe this should be directed at the tagging list but I thought I
>> would get thoughts from the US community since we seem to be the ones
>> using the tag incorrectly (according to the wiki)
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:surface
>>
>> Toby
>>
>> --
>>
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Mittwoch, 18. April 2018 um 23:26 Uhr
> Von: "Michael Reichert" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> An deiner Stelle würde ich die DWG bitten, ihn zu verwarnen, weil sein
> Verhalten demotivierend und störend ist. Weitere Maßnahmen gegen ihn
> können bei Bedarf später ergriffen werden.

Erinnert sich noch jemand daran, dass OSM selbst disruptiv und störend
war, solange es sich verbreitert hat?  Eine klare Motivation in der An-
fangsphase war, das Geschäftsmodell von Druckkartendiensten, wie auch
das von Google Maps in Frage zu stellen, bzw. unter Druck zu setzen.

Mit Verwarnsüchten und "Maßnahmen" tritt man die Bemühungen der Frei-
willigen, eine "freie Weltkarte" zu gestalten, zu erhalten und fördert
klar den Kommerz.  Andere Meinungen und Methoden haben das Projekt
schon immer bereichert, weil man dadurch eine wesentlich bessere
Sichtweise auf die Alternativen gewinnen kann, die ein geg. Problem
lösen.  Demotivierend ist, wenn es nicht gelingt, dieses Ökosystem
in seiner Vielfalt zu erhalten, imho.  Außerdem sollte man sich an
die beiden goldenen Regeln von OSM erinnern.


Gruß

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Mittwoch, 18. April 2018 um 23:41 Uhr
> Von: "Hartmut Holzgraefe" 
> An: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> "There is not clear consensus yet ..."
> 
> "That being said, when the way is a highway, it usually is most accurate 
> to include a gap, so that the area ends by the side of the road and does 
> not share nodes with the road's way. This is because highway ways 
> usually are traced along the centerline of the road, and it is unlikely 
> that the area being tagged actually extends to the center of the road."
> 
> Das liest sich beides irgendwie nicht so wirklich wie dass was ich mir
> unter:
> 
> "gemäß Wiki anerkannte Methode"

Es liest sich so, als dass sowohl das eine als auch das andere vorzufinden
ist und weder das eine noch das andere falsch ist.  Die Wiki-Seite gibt
wieder, was auch in der Mailing-Liste anhand dieser Diskussion zu sehen
ist:  Es gibt keine klare Einigung unter den Beitragenden.

Nichts desto trotz tendiert die Wiki-Seite dazu eine Empfehlung für das
Entkleben auszusprechen (ebenso ohne klaren Konsens, wird wohl pers.
Meinung des Wiki-Schreibers sein).

Außerdem stellen diese Zitate klar, dass nicht /die/ "centerline" ge-
mappt wird, sondern der highway (Weg/Straße) unter /Zuhilfename/ einer
solchen.  Zudem "usually", d.h. üblicherweise/grob/ungefähr - man kann
sich nicht in allen Gebieten darauf verlassen, dass der 1-dimensionale
Vertreter (Linienzug) in den Daten für das 3-dimensionale Objekt vor Ort
stets die Position der Weg/Straßen-Mittellinie wiedergibt.  Stammen die
Daten aus einem GPS-Trace ist das sogar unwahrscheinlich, da der GPS-
Empfänger seltenst auf der Mittellinie entlang geführt werden wird.


Gruß

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

Re: [OSM-talk-fr] Piste cyclable bidirectionnelle au centre de la chaussée

[marc marc]

Le 18. 04. 18 à 19:51, Virgile Kéré a écrit :
> piste piste cyclable bidirectionnelle en centre de la chaussée, 
> comme ce qui a été fait Bd Agutte-Sembat à Grenoble (photo : 
> https://twitter.com/ymongaburu/status/950349177980116992?lang=bg )

les travaux sont finit ?!?
le message disait en janvier que c'était une réunion d'information pour 
des travaux prévu à l'automne (et donc l'image du premier message est 
photoshopée ou d'ailleurs)
c'est rare d'avoir des travaux publics en avance sur le planning :)

pour les tags :
cycleway = lane est ambigu car à l'origine il dit qu'il y a une bande de 
chaque côté de la route. c'est très bricolé de s'en servir de c'est pas 
2 mais une bande et pas sur le côté mais au centre.
le seul avantage c'est que le routing fonctionnera partiellement.
cycleway:center=lane me semble plus pratique à long terme
à voir s'il faut demander son support dans les logiciels d'itinéraire

pour l'aspect bidirectionnel de la bande cycliste
oneway=yes
oneway:bicycle=no
https://wiki.openstreetmap.org/wiki/Key:oneway
mais cela n'a aucun sens si la route elle même n'est pas en sens unique.
je reprendrais pour cela une partie des tags d'Antoine
lanes=2 (selon le wiki c'est le nombre de bandes motorisées)
bicycle:lanes=yes|designated|yes ou bicycle:lanes=no|designated|no selon 
l'obligation ou non d'emprunter la bande centrale
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Gravel roads and surface tags in the US

[Jack Burke]

I've been tagging roads like that as compacted, once I learned more about the 
surfacing tech.

-jack

-- 
Typos courtesy of fancy auto spell technology

On April 18, 2018 6:19:07 PM EDT, Toby Murray  wrote:
>I recently bought a gravel bicycle to ride on the many gravel roads in
>Kansas. Like this one:
>https://www.mapillary.com/app/?pKey=nYO4JI46L0SWzNAQlLT4kA=photo
>
>First question: What would you call this road? Obviously I am calling
>it a "gravel road" but a couple of people have said they would call it
>a "dirt road" so I'm curious if there are any other common terms to
>describe this type of road in different regions of the US.
>
>Second question: How would you tag this road? There is a
>surface=gravel tag that is in pretty common usage in Kansas and
>neighboring states. However looking at the wiki page for the surface
>tag[1], this is not wiki-correct. According to that page
>surface=gravel is to be used for large rocks (4-8cm) that are laid
>down loosely like those typically used as ballast on railroad beds. I
>believe The Mapillary picture I linked to would be considered
>surface=compacted according to the wiki because the rocks are much
>smaller and the surface is stabilized with a binding agent. There is a
>big difference between the two when it comes to bicycle riding.
>Railroad ballast is bone jarring and flat tire inducing whereas gravel
>roads are pretty manageable on the right kind of bike.
>
>But If you call something a "gravel road" and there is a "gravel"
>option in the editor preset for the surface tag, people are going to
>choose the gravel option and not look for "compacted" since that is
>not a common term here. I assume it is a more common term in the UK
>and that is why it is used in OSM.
>
>And lastly there are trails that are surfaced with a similar material
>but crushed to a smaller size like here:
>https://www.mapillary.com/app/?pKey=iQNqP-dfQ-Rm6AD9REMsgQ=photo
>
>I'm trying to decide if that is better as surface=compacted or
>surface=fine_gravel although fine_gravel seems to be a slightly
>different process from what I see on the wiki.
>
>Maybe this should be directed at the tagging list but I thought I
>would get thoughts from the US community since we seem to be the ones
>using the tag incorrectly (according to the wiki)
>
>[1] https://wiki.openstreetmap.org/wiki/Key:surface
>
>Toby
>
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Gravel roads and surface tags in the US

[Toby Murray]

I recently bought a gravel bicycle to ride on the many gravel roads in
Kansas. Like this one:
https://www.mapillary.com/app/?pKey=nYO4JI46L0SWzNAQlLT4kA=photo

First question: What would you call this road? Obviously I am calling
it a "gravel road" but a couple of people have said they would call it
a "dirt road" so I'm curious if there are any other common terms to
describe this type of road in different regions of the US.

Second question: How would you tag this road? There is a
surface=gravel tag that is in pretty common usage in Kansas and
neighboring states. However looking at the wiki page for the surface
tag[1], this is not wiki-correct. According to that page
surface=gravel is to be used for large rocks (4-8cm) that are laid
down loosely like those typically used as ballast on railroad beds. I
believe The Mapillary picture I linked to would be considered
surface=compacted according to the wiki because the rocks are much
smaller and the surface is stabilized with a binding agent. There is a
big difference between the two when it comes to bicycle riding.
Railroad ballast is bone jarring and flat tire inducing whereas gravel
roads are pretty manageable on the right kind of bike.

But If you call something a "gravel road" and there is a "gravel"
option in the editor preset for the surface tag, people are going to
choose the gravel option and not look for "compacted" since that is
not a common term here. I assume it is a more common term in the UK
and that is why it is used in OSM.

And lastly there are trails that are surfaced with a similar material
but crushed to a smaller size like here:
https://www.mapillary.com/app/?pKey=iQNqP-dfQ-Rm6AD9REMsgQ=photo

I'm trying to decide if that is better as surface=compacted or
surface=fine_gravel although fine_gravel seems to be a slightly
different process from what I see on the wiki.

Maybe this should be directed at the tagging list but I thought I
would get thoughts from the US community since we seem to be the ones
using the tag incorrectly (according to the wiki)

[1] https://wiki.openstreetmap.org/wiki/Key:surface

Toby

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Hartmut Holzgraefe]

On 18.04.2018 20:07, Florian Lohoff wrote:


==
Das progressive Teilen von Nodes durch Flächen und Wegen ist eine gemäß 
Wiki anerkannte Mappingmethode. Der Weg repräsentiert dabei nicht 
ausschließlich die Fa
hrbahmitte sondern insbesondere in Verbindung mit dem width-Attribut, 
hilfsweise auch mit Standardwerten, die gesamte Fahrbahn. Selbstverständlich 
geht der Pa
rkplatz nicht bis zur Fahrbahnmitte. Das wird mit dieser Mappingmethode 
auch nicht behauptet. Wenn das Dein Renderer oder Dein Editor anders darstellt 
ist das
 kein Fehler. 
https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Areas_and_Ways_Sharing_Nodes
==



"lustig" dass die verlinkte Wikiseite in dem Abschnitt auch sagt:

"There is not clear consensus yet ..."

"That being said, when the way is a highway, it usually is most accurate 
to include a gap, so that the area ends by the side of the road and does 
not share nodes with the road's way. This is because highway ways 
usually are traced along the centerline of the road, and it is unlikely 
that the area being tagged actually extends to the center of the road."


Das liest sich beides irgendwie nicht so wirklich wie dass was ich mir
unter:

"gemäß Wiki anerkannte Methode"

vorstellen würde?


--
hartmut

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Michael Reichert]

Hallo Flo,

Am 18.04.2018 um 20:07 schrieb Florian Lohoff:
> Das trolling von OF0 geht wieder los - soifz ... 
> 
>   Hi flohoff,
> 
>   OF0 has left a comment on a map changeset you are watching created by 
> HolgerJeromin at 2018-04-18 18:03:52 UTC
>   with comment 'Details per Luftbild'
> 
>   ==
>   Das progressive Teilen von Nodes durch Flächen und Wegen ist eine gemäß 
> Wiki anerkannte Mappingmethode. Der Weg repräsentiert dabei nicht 
> ausschließlich die Fa
>   hrbahmitte sondern insbesondere in Verbindung mit dem width-Attribut, 
> hilfsweise auch mit Standardwerten, die gesamte Fahrbahn. Selbstverständlich 
> geht der Pa
>   rkplatz nicht bis zur Fahrbahnmitte. Das wird mit dieser Mappingmethode 
> auch nicht behauptet. Wenn das Dein Renderer oder Dein Editor anders 
> darstellt ist das
>kein Fehler. 
> https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Areas_and_Ways_Sharing_Nodes
>   ==
> 
>   More details about the changeset can be found at 
> http://www.openstreetmap.org/changeset/58204223.
> 

An deiner Stelle würde ich die DWG bitten, ihn zu verwarnen, weil sein
Verhalten demotivierend und störend ist. Weitere Maßnahmen gegen ihn
können bei Bedarf später ergriffen werden.

Viele Grüße

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [OSM-talk-fr] Piste cyclable bidirectionnelle au centre de la chaussée

[Philippe Verdy]

On en a parlé il y a quelques jours sur cette liste, et la voie cyclable
sur la même chaussée sans séparation correspond trait pour trait aux
cycleway:left=lane et cycleway:right=lane qui correspondent aux
cycleway=lane pour les deux côtés à la fois. Les propositions 1 et 2
s'appuient aussi sur cycleway=lane. Mais le côté est indiqué avec ":left"
ou ":right" ici serait ":center".
Ce que le ":center" n'indique pas (mais ":left" et ":right" non plus
directement...) c'est le sens de circulation sur ce lane. Dans le cas
":left" ou ":right" le sens est dépendant du côté de circulation de la
route (côté de croisement des véhicules se dépassant en contre-sens) et
"cycleway:left" indique le sens "backward" en France ("forward" au
Royaume-Uni), en supposant que les cycleways sont unidirectionnels.
On on a bien des tag "oneway=yes/no/-1" pour les voies des véhicules à
moteur, mais cela s'applique aussi aux voies cyclables, bien que la
majorité des voies cyclables latérales sont unidirectionnelles (quand il y
en a une de chaque côté) Mais cela n'indique pas si une voie cyclable
centrale est unidirectionnelle ou bidirectionnelle (je pense que dans le
cas de voie central, cette voie cyclable est par défaut bidirectionnelle,
surtout s'il n'y a pas de séparation physique comme une bordure: les
cyclistes se croisent en roulant chacun près de la ligne de rive, dans le
même sens que les véhicules à moteur dans les voies latérales.

Une chose en plus qu'indique normalement une voie cyclable centrale c'est
l'interdiction de la franchir pour les véhicules à moteur (cela implique
pour eux une interdiction de demi-tour, mais il peut y avoir de très brèves
interruptions de la ligne continue dans le cas des sorties de résidences
qui peuvent éventuellement avoir le droit de franchir cette voie centrale
pour y entrer ou en sortir, et bien sûr un droit en cas d'urgence ou
d'obstruction de la voie de circulation normale, la voie cyclable servant
alors de voie de secours et dégagement.

Je pense donc que "cycleway:center=lane" convient et qu'au besoin on peut y
ajouter un suffixe pour le "oneway=yes" applicable ou pas à la voie
centrale. Le "cycleway:center=lane" devrait impliquer "oneway=yes" pour les
véhicules à moteur (même si on ne l'a pas mis) mais "oneway=no" par défaut
pour les cycles.

On a encore le cas de la voie centrale cyclable partagée avec les bus: là
le cas le plsu courant est que ce "share_lane" est unidirectionnel (trop
dangereux de faire se croiser sur la même voie centrale des bus et des
vélos!). Le marquage au sol doit aussi être différent (d'un coté une ligne
continue le long de la voie carossable en contre-sens, de l'autre une ligne
de rive dans la voie carossable de même sens, et cette voie nettement plus
large pour les bus doit aussi avoir un marquage qu'elle est réservée à la
fois aux bus et vélos, et éventuellement aux véhicules d'urgence; s'il y a
des vélos je pense qu'elle est cependant interdite aux taxis même si les
bus peuvent y aller et l'utilisent pour desservir des arrêts situés au
centre d'un boulevard aux endroits où la ligne de rive devient un ilôt
séparateur avec une plateforme proche d'un passage piéton protégé et où les
voies carossables sont restreintes en largeur totale et en nombre).

Voici un  cas schématique:


Passage piéton
==\
 /===

 ==
<
▀▀  <
______________<   <   <   <   <   <   <
 ▀▀   <  <________

▀▀
< voie(s) à contre-sens unique <<
▀▀ ↖  ↖

___/
 ▀▀\__
|\  |\  |\   |\  |\  |\  |
 ▀▀
 BUS et cycles >>>  |  \|  \|  \ |  \|  \|  \|
 ▀▀  BUS et cycles >
___  ___  ___ ___ ___ ___ ___ ___ ___ ___
__/===▀▀=\_ ___ ___ ___ ___ ___ ___
___
\  îlot   ARRÊT BUS
 |▀▀|/
 voie(s) à sens unique >>   ↘↘
\==▀▀/
______________
 ▀▀ __________
  >   >   >   >   >   >   >
 ▀▀  >  >
   >>
▀▀ 
 ===
▀▀===
/
  \===

Ici je m'intéresse moins au passage piéton ou à l'ilot avec l'arrêt de bus,
qu'au fait que la voie centrale est unidirectionnelle mais partagée entre
bus et vélos et pas séparée des voies unidirectionnelles de chaque côté.

Pour le cas de 

Re: [Talk-cz] ruční GPS navigace

[Miroslav Suchý]

Dne 5.2.2018 v 13:43 xkomc...@centrum.cz napsal(a):
> Kdyby tě zajímaly nějaké podrobnosti ohledně toho Oregonu, tak napiš
> klidně i soukromě, co vím, povím ;-)

Tak jsem nakonec skoncil u Garmin Oregon 700 a uz se tesim az to vyzkousim.

Mam jeden dotaz: Da se ten Garmin nejak propojit s Android telefonem,
tak aby telefon pouzival tu GPSku z Garmina? Nainstaloval jsem si GPS
Bluetooth aplikaci, spojil telefon s Garminem pres bluetooth, zapnul
jsem si developer setting a nastavil GPS Bluetooth aplikaci jako mock
GPS, ale kdyz dam v GPS Bluetooth pripojeni na Garmin (ktereho vydi),
tak se mu nedari pripojit.

Je to marna snaha? Nebo to jde a mam vytrvat?
Kdyz to nepujde, tak to nevadi. Jenom zkousim kde jsou hranice
technologie :)

Mirek

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

Re: [Talk-at] Vienna Geo Meetup #1

[Rudolf Mayer]

On 04/18/2018 09:35 PM, Johann Haag wrote:
Wie stark der Bezug zu OpenStreetMap ist, erkennt man bereits an der 
Einladungs- Webseite mit Google Maps als Veranstaltungskarte. 
https://www.meetup.com/de-DE/ViennaGeo/events/248598523/?eventId=248598523


Hier schmückten sich welche mit falschen Federn.



Die Karte wird von der *Plattform* Meetup.com angezeigt - das ist halt 
das, was die Betreiber verwenden.

Das kann man kaum den Organisatoren des Geo Meet-Ups vorwerfen, oder?

Lg
Rudi

Am 6. April 2018 um 11:26 schrieb Manuela Schmidt 
>:


Liebe TalkAT-Liste,

ich darf euch auf folgendes Event am kommenden Dienstag hinweisen:

Am 10. April trifft sich die Wiener Geo Community zum fachlichen
Austausch im Museumsquartier. Beim ersten Vienna Geo Meetup
berichtet Wolfgang Jörg von der Stadt Wien über ViennaGIS, das
wichtigste Open Government Geo Service in Wien und Österreich, Anita
Graser erklärt die Analyse von Bewegungsdaten in der angewandten
Forschung und Robert Koch berichtet über die FOSSGIS 2018.
OpenStreetMap kommt bei den Folgetreffen noch gut dran.
–
https://www.meetup.com/de-DE/ViennaGeo/events/248598523/?eventId=248598523


Be welcome!

LG Manuela

-- 
DI(FH) Manuela Schmidt

Research Group Cartography
Vienna University of Technology
http://cartography.tuwien.ac.at 

Also visit me at http://manuschmidt.com
he...@manuschmidt.com  // +43-681-10378481

DVR: 0005886


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





--
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at 


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



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

Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, Hilfsorganisationen

[Martin Koppenhoefer]

sent from a phone

> On 18. Apr 2018, at 20:26, Daniel Korn  wrote:
> 
> Ich habe weiterhin "amenity=ambulance_station" (es gab nur 25 Stück) händisch 
> auf "emergency=ambulance_station" in ganz Deutschland angepasst [1]. Es gab 
> nur ein Element bei dem eindeutig war, dass es sich sicher nicht um eine 
> Rettungswache handelt, daher fehlt das entsprechende Tagging [2].


edits in “ganz Deutschland” bei denen man das tagging systematisch ändert kann 
man nur machen nachdem man sie angekündigt hat und es halbwegs Einigkeit gab, 
dass man das machen will.

https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

zugegebenermaßen sind 24 geänderte Objekte evtl. gerade noch so in einer 
Grauzone von Insignifikanz.

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

Re: [Talk-at] Vienna Geo Meetup #1

[Johann Haag]

Wie stark der Bezug zu OpenStreetMap ist, erkennt man bereits an der
Einladungs- Webseite mit Google Maps als Veranstaltungskarte.
https://www.meetup.com/de-DE/ViennaGeo/events/248598523/?eventId=248598523

Hier schmückten sich welche mit falschen Federn.

Grüße Johann

Am 6. April 2018 um 11:26 schrieb Manuela Schmidt <
manuela.schm...@tuwien.ac.at>:

> Liebe TalkAT-Liste,
>
> ich darf euch auf folgendes Event am kommenden Dienstag hinweisen:
>
> Am 10. April trifft sich die Wiener Geo Community zum fachlichen Austausch
> im Museumsquartier. Beim ersten Vienna Geo Meetup berichtet Wolfgang Jörg
> von der Stadt Wien über ViennaGIS, das wichtigste Open Government Geo
> Service in Wien und Österreich, Anita Graser erklärt die Analyse von
> Bewegungsdaten in der angewandten Forschung und Robert Koch berichtet über
> die FOSSGIS 2018. OpenStreetMap kommt bei den Folgetreffen noch gut dran.
> – https://www.meetup.com/de-DE/ViennaGeo/events/248598523/?eve
> ntId=248598523
>
> Be welcome!
>
> LG Manuela
>
> --
> DI(FH) Manuela Schmidt
> Research Group Cartography
> Vienna University of Technology
> http://cartography.tuwien.ac.at
>
> Also visit me at http://manuschmidt.com
> he...@manuschmidt.com // +43-681-10378481
>
> DVR: 0005886
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>



-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] AGIT 2018

[Johann Haag]

Leider habe ich diesmal keine Zeit, schön dass OpenStreetMap mit einem
eigenen Stand präsent ist.
Bei meiner letzten Teilnahme 2016 habe ich doch einige wertvolle
Informationen mitnehmen dürfen. https://youtu.be/-gUFIwF-gi4

Grüße Johann

Am 17. April 2018 um 00:40 schrieb Markus Mayr 
:

> Hallo, liebe Mapper/innen!
>
> Vom 04.07.2018 - 06.07.2018 findet die AGIT 2018, Österreichs größte
> Konferenz und Fachmesse für Geoinformation in Salzburg statt. Auch dieses
> Jahr ist das OpenStreetMap Projekt dort vertreten.
>
> Ich möchte auf jeden Fall wieder dort sein und freue mich über
> Unterstützung vor Ort. Die genauen Zugangsmodalitäten sind mir noch nicht
> ganz klar, aber unter der Annahme, dass es wie in den Vorjahren ablaufen
> wird, gibt es vielleicht wieder Gastkarten (ich werde mich erkundigen,
> falls es Freiwillige gibt). Falls weitere Kosten entstehen, bitte im
> Vorfeld mit dem OSM-AT Verein Kontakt aufnehmen, dieser kann da bestimmt
> auch etwas aushelfen.
>
> Beste Grüße,
> Markus (ScubbX)
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>



-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk-fr] Piste cyclable bidirectionnelle au centre de la chaussée

[Antoine Riche]

Salut Virgile.

Je suppose que par "singer Nantes" tu fais référence au Cours des 50 
otages (https://www.openstreetmap.org/way/375740563) qui est une piste 
cyclable car séparée des chaussées à droite et à gauche par un rebord 
conséquent.


Je te proposerais bien d'utiliser bicycle:lanes (2831 occurences), que 
l'on trouve documenté ici : 
https://wiki.openstreetmap.org/wiki/Lanes#Crossing_with_a_designated_lane_for_bicycles


Donc en se basant sur ta photo :
highway=*
lanes=3
cycleway=lane
bicycle:lanes=yes|designated|yes

Antoine.

Le 18/04/2018 à 19:51, Virgile Kéré a écrit :

Salut à tous.

Je m'interroge sur comment tagger une piste piste cyclable 
bidirectionnelle en centre de la chaussée, comme ce qui a été fait Bd 
Agutte-Sembat à Grenoble (photo : 
https://twitter.com/ymongaburu/status/950349177980116992?lang=bg )


L’inspiration principale étant le cours des 50 otages à Nantes, j'ai 
d'abord pensé m'en inspirer. Sauf qu'à Nantes il y a une séparation 
physique (dénivellation) qui justifie la représentation en ways 
séparés. Là où à Grenoble, ce n'est que de la peinture, donc en 
principe un seul way.


J'ai écumer les "cycleway" sur tag_info, rien ne semblerait correspondre.

J'hésite entre :

1/ mettre "cycleway = lane" + une description expliquant la situation

2/ mettre "cycleway = lane" + bricoler un "cycleway_position=center" + 
une description expliquant la situation


3/ bricoler un "cycleway=center_lane" + une description expliquant la 
situation


4/ singer Nantes

J'aime bien la seconde proposition, car elle permettrait de tagger 
aussi des pistes bidirectionnelles latérales sans séparation physique 
(ou j'ai déjà vu ça une fois en France). La troisième me plaît aussi. 
Qu'en pensez-vous ?


Virgile


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





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-be] Nodes or areas to tag amenities

[Ubipo .]

I agree on the separation of building:part=* for architectural distinct
building parts and room=* for mostly functionaly distinct parts of a
building. I think there should be a general indoor=part or something (don't
quote me on that tag, I can't really think of something better). This would
then replace the room=restaurant and would serve to separate functionaly
different parts of a building. Another example apart from a restaurant is a
building containing both classrooms and a library. The library would be
tagged as indoor=part and the relevant amenity (with optional room=*'s
inside that) and the classrooms would just be tagged as room=* and
indoor=room as they don't really form a whole.

On Wed, Apr 18, 2018, 18:54 marc marc  wrote:

> @ubipo for indoor=level, I suppose you mean indoor=yes indoor=thenumber :)
>
> building:part is for a part of a building where tag related to the
> building itself doesn't have the same value for one part <> another part
> for exemple a building that have one part with one level :
> building:part=yes
> building:levels=1
> and another part with 2 levels
> building:part=yes
> building:levels=1
> both parts make one building with building=yes on the outline
>
> but inside a buidling, room nearly never affect the building "external
> look"
> so it should not be any building:part tag on a room,
> except if a building:part is made by only one room of course.
>
> for room=restaurant on amenety=restaurant, I've been talking with
> PanierAvide who add this to the wiki. he agree that this is not good.
> we are working on on howto make it better.
>
> Le 18. 04. 18 à 18:43, Pieter Vander Vennet a écrit :
> > I have some experience with indoor mapping.
> >
> > I would invite you guys to have a look at my work of the Blekerij in
> > Gent
> > <
> https://openlevelup.net/old/?lat=51.060092=3.732321=19=0=0=1=0=0=0=0=0>,
>
> > as example. Toilets can be mapped as either a point or area with
> > 'amenity=toilets, indoor=yes; level=0' (or perhaps 'level=0-2', e.g. for
> > a building with toilets on the same location on floors 0 till 2.). Note
> > that 'level=0' is the ground floor (gelijkvloers).
> >
> > I have no experience with the building:part=yes. I assume that
> > indoor=yes implies 'building:part=yes' and that 'building:part' is
> > rather used for roofs etc...
> >
> >
> >
> >
> > Met vriendelijke groeten,
> > Pieter Vander Vennet
> >
> > 2018-04-18 18:13 GMT+02:00 joost schouppe  > >:
> >
> > How does this relate to the building:part=yes strategy that
> > L'imaginaire has been playing with, e.g.
> > https://www.openstreetmap.org/way/283645760
> > 
> >
> > 2018-04-18 15:56 GMT+02:00 Ubipo .  > >:
> >
> > After furter consideration I think indoor=level combined with
> > amenity=restaurant should solve most problems.
> > Improving the map would then be as simple as not editing the
> > general indoor=level and just drawing new ways for individual
> > rooms (not tagged amenity=restaurant).
> >
> > A restaurant on multiple floors would indeed be tricky as
> > indoor=level implies a single level, although I think just
> > adding level=0;1 shouldn't be that bad, right?
> >
> > On 18 April 2018 at 13:58, Marc Gemis  > > wrote:
> >
> > how does someone "improve" your mapping to add a separate
> > area for
> > room=toilets ? nested room areas ? split it off ?
> >
> > m.
> >
> > On Wed, Apr 18, 2018 at 12:43 PM, Ubipo .
> > >
> wrote:
> >  > Regarding the housenumbers: street and number is as said
> > probably not needed
> >  > and better reserved for the actual building, although a
> > specialised
> >  > addr:addition=a could be useful for the rooms.
> >  > Regarding room=restaurant, I think that tag is perfectly
> > fine. It just
> >  > indicates the restaurant in it's entirety, with dining
> > room, kitchen etc.
> >  >
> >  > On Wed, Apr 18, 2018, 12:10 marc marc
> >  > > wrote:
> >  >>
> >  >> for the addr : it look like strange that the room is in
> > a building that
> >  >> doesn't have the same addr:housenumber as the building.
> >  >>
> >  >> for multiple floors poi, you can draw all room with
> > level=* tag
> >  >> or as a first step only use indoor=yes for the whole area
> >  >>
> >  >> 

Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, Hilfsorganisationen

[Daniel Korn]

Ich habe weiterhin "amenity=ambulance_station" (es gab nur 25 Stück) 
händisch auf "emergency=ambulance_station" in ganz Deutschland angepasst 
[1]. Es gab nur ein Element bei dem eindeutig war, dass es sich sicher 
nicht um eine Rettungswache handelt, daher fehlt das entsprechende 
Tagging [2].


Gruß
Daniel

[1] https://www.openstreetmap.org/changeset/58210390
[2] https://www.openstreetmap.org/node/2377789088/history

Am 18.04.2018 um 17:18 schrieb Daniel Korn:
Du hast recht, da habe ich wohl einen falsch angefasst gehabt. Ist 
korrigiert [1].


[1] https://www.openstreetmap.org/changeset/58204999

Am 18.04.2018 um 17:10 schrieb Scholtes, Martin:
Naja da warst du vllt etwas zu schnell oder gilt way 116174430 nicht 
als rettungswache?

Vllt eine genauere Einzelfallprüfung statt rundum Schlag.

Gruß Martin
Von meinem Huawei-Mobiltelefon gesendet

 Originalnachricht 
Betreff: Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, 
Hilfsorganisationen

Von: Daniel Korn 
An: talk-de@openstreetmap.org
Cc:


Ich habe in Deutschland die Rettungswachen von den Bergwachten nun
differenziert [1, 2].

Gruß
Daniel

[1] https://www.openstreetmap.org/changeset/58204411
[2] http://overpass-turbo.eu/s/y14

Am 18.04.2018 um 13:38 schrieb Tom Pfeifer:

Das Taggen der Hilfsorganisationen ist recht chaotisch, daher ist ja
seit langem der "Emergency-cleanup" im Wiki annonciert, wird aber nur
halbherzig betrieben.

Für die Bergrettung würde sich "emergency=mountain_rescue" anbieten,
bisher 2 Verwendungen.

Für den Zivilschutz hatte ein Australier mal "emergency=ses_station"
etabliert, was wegen des nationalen Acronyms SES ungeeignet ist [1].

Bei den Diskussionen dort, ob emergency=disaster_response geeignet
wäre, stieß ich auf die derzeitige Verwendung beim deutschen
Technischen Hilfswerk (THW) nach dem Schema amenity=emergency_service
+ emergency_service=technical, was einem Proposal von 2008 [2] folgt.

[1] https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dses_station
[2]
https://wiki.openstreetmap.org/wiki/Proposed_features/Emergency_service

Tom

On 15.04.2018 14:04, Lena Essig wrote:

Hallo zusammen,

mir ist aufgefallen, dass bei der Suche nach
"emergency"="ambulance_station"
nicht nur Rettungswachen angezeigt werden, sondern auch Bergwachten 
oder

auch Ortsvereine.
Nur sehr wenige der Bergwachten sind mit "amenity"="mountain_rescue"
getaggt.
Da Bergwachten nur besondere Einsatzarten übernehmen, sollten sie von
normalen Rettungswachen unterschieden werden. Ebenso Ortsvereine der
einzelnen Hilfsorganisationen, da sie nichts mit dem Rettungsdienst
zu tun
haben.
Wie ist denn die allgemeine Regelung für Orstvereine oder
Katastrophenschutzzentren?


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


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



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



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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

On Mon, Apr 02, 2018 at 12:03:50AM +0200, Florian Lohoff wrote:
> 
> Hi,
> 
> ich habe vor ein paar Wochen angefangen in meinem Dunstkreis
> (Ostwestalen-Lippe) Systematisch alle "verklebten Flächen und Wege"
> aufzulösen. Ich finde das selber zum bearbeiten extrem nervig und vor
> allem sind die Daten zumeist extrem ungenau - Teilweise noch aus Bing
> Zeiten, riesige Landuses die willkürlich mit Straßen verbunden sind.

Das trolling von OF0 geht wieder los - soifz ... 

Hi flohoff,

OF0 has left a comment on a map changeset you are watching created by 
HolgerJeromin at 2018-04-18 18:03:52 UTC
with comment 'Details per Luftbild'

==
Das progressive Teilen von Nodes durch Flächen und Wegen ist eine gemäß 
Wiki anerkannte Mappingmethode. Der Weg repräsentiert dabei nicht 
ausschließlich die Fa
hrbahmitte sondern insbesondere in Verbindung mit dem width-Attribut, 
hilfsweise auch mit Standardwerten, die gesamte Fahrbahn. Selbstverständlich 
geht der Pa
rkplatz nicht bis zur Fahrbahnmitte. Das wird mit dieser Mappingmethode 
auch nicht behauptet. Wenn das Dein Renderer oder Dein Editor anders darstellt 
ist das
 kein Fehler. 
https://wiki.openstreetmap.org/wiki/Editing_Standards_and_Conventions#Areas_and_Ways_Sharing_Nodes
==

More details about the changeset can be found at 
http://www.openstreetmap.org/changeset/58204223.

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

[OSM-talk-fr] Piste cyclable bidirectionnelle au centre de la chaussée

[Virgile Kéré]

Salut à tous.

Je m'interroge sur comment tagger une piste piste cyclable 
bidirectionnelle en centre de la chaussée, comme ce qui a été fait Bd 
Agutte-Sembat à Grenoble (photo : 
https://twitter.com/ymongaburu/status/950349177980116992?lang=bg )


L’inspiration principale étant le cours des 50 otages à Nantes, j'ai 
d'abord pensé m'en inspirer. Sauf qu'à Nantes il y a une séparation 
physique (dénivellation) qui justifie la représentation en ways séparés. 
Là où à Grenoble, ce n'est que de la peinture, donc en principe un seul way.


J'ai écumer les "cycleway" sur tag_info, rien ne semblerait correspondre.

J'hésite entre :

1/ mettre "cycleway = lane" + une description expliquant la situation

2/ mettre "cycleway = lane" + bricoler un "cycleway_position=center" + 
une description expliquant la situation


3/ bricoler un "cycleway=center_lane" + une description expliquant la 
situation


4/ singer Nantes

J'aime bien la seconde proposition, car elle permettrait de tagger aussi 
des pistes bidirectionnelles latérales sans séparation physique (ou j'ai 
déjà vu ça une fois en France). La troisième me plaît aussi. Qu'en 
pensez-vous ?


Virgile


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

Re: [Talk-es] Propuesta: cambiar la categoría de algunas carreteras nacionales en base a su uso y estado actuales.

[yo paseopor]

No estoy de acuerdo con los argumentos aquí expresados. El hecho de que una
etiqueta general como highway esté dedicada a toda una vía es de lo más
aleatorio que se puede hacer en un mapa moderno (de esta nueva era de la
información) y sólo responde a una realidad, más que nada administrativa en
este caso.Para eso ya tenemos la etiqueta ref (que sí se mantiene
invariable), y lo puedo demostrar con un ejemplo o dos:

-Los traspasos de carreteras entre administraciones. No por vías
alternativas, sino en función de sus estatutos de autonomía. No queda muy
lejos aún el período en que todas las carreteras dependían de la
administración central, bien a través del Ministerio de Obras Públicas y
Urbanismo (MOPU) o bien a través de las Diputaciones Provinciales.

Pues bien, en función de estatutos de autonomía y otras leyes estas
carreteras se fueron trasladando a sus diversas comunidades autónomas.La
gran mayoría eran Comarcales...pero hubo alguna que otra Nacional. Un
ejemplo que tengo cercano es el de una Comarcal, la C-246, que iba de
Barcelona a Valls, con sus kilometrajes etc. Como comprobarás los mapas de
la época (hasta los 2000 no se hizo en Catalunya el cambio de
nomenclaturas, hay mapas del ign de esa época a porrillo) se consideraba
una misma ruta aunque primero pasaba por la costa con gran tráfico, para
después ir hacia el interior, carretera malísima de curvas, en la que la
gente prefería usar vías alternativas y con tráfico escaso.

Se suceden los traspasos y acuerdos. No la busques en el mapa porque no
existe. Encontrarás la C-31... y la C-51, porque ahora las carreteras
catalanas en su gran mayoría siguen un criterio geográfico no radial. Y el
eje de la Costa tiene un número , el 31 y el eje interior tiene otro , el
51. Entre medio se han sucedido inversiones, desdoblamientos, nuevos
trazados... ¿Tiene sentido que en el mapa se mostrara la carretera a lo
largo de los 300 y pico kilómetros de costa? No, de igual manera que porque
sea una carretera autonómica cuando es una autovía los carteles cambian de
color sin que los coches se vuelvan locos o a los conductores les explote
la cabeza ante tal dificultad de disquisición por seguir por una misma
carretera que ahora tiene carteles diferentes.

Vale, perdón por la broma , me he cachondeado bastante, no te lo voy a
negar, y además de ejemplo he usado una carretera autónomica.
Lo voy a hacer con una Nacional, porque ... con las nacionales también pasa.
Porque hay nacionales que no estaban en los mapas de cuando el dictador
vivía y se diseñó la red radial de carreteras. Hay una que nació en los 80:
la N-260 o eje Pirenaico. Va desde Portbou a Sabiñánigo. Y voy a ser
benevolente con el gobierno español , responsable de la carretera y no voy
a comentar su estado. Sólo diré que en sus 400 km y pico kilométros hay de
todo, desde autovías (A-26) a tramos que no se merecen la calificación de
nacional. Y que por suerte en nuestro mapa, ni en Catalunya, ni en Aragón
tiene la misma categoría en todo su trazado, y si me lanzo a la piscina os
reto a todos a que traceis una ruta desde Sabiñánigo a Portbou con
cualquier servicio abierto o propietario a ver cuantos puntos intermedios
necesitais marcar para que haga el recorrido entero por esa nacional.

Habreis comprendido...que no, y que por tanto que sea la misma referencia
no sólo estoy de acuerdo sinó que debe ser así, porque es como la
administración le llama, nunca va a dejar de ser Nacional porque así se
llaman las carreteras que dependen del Ministerio de Fomento ahora, es la
N-260 y aunque fuera tertiary llevará ese número y todo el mundo podrá
hacerle los mapas y rutas que quiera con ella. Ahora bien, no es factible,
ni viable, ni posible, ni lógico que tenga la misma categoría en toda su
extensión. Y para ello sólo haría falta leer la página de trunk y cómo
empieza:

"Use highway =trunk for
high performance roads that don't meet the requirement for motorway
 "

Os voy a poner otro caso: la N-340. Al margen de traspaso o no es un claro
caso de cómo se invierte en unas zonas y como no se hace en otras, aunque
reconozco que en sus más de mil kilómetros (yo vivo cerca del 1200), de
Cádiz a Barcelona es muy difícil mantener las mismas características. No
creo que soporte el mismo tráfico en la costa marbellí que en el Penedès,no
creo que sea la misma situación en la provincia de Murcia que en la de
Castellón,  cuando ya no hablo de que si recordais anteriormente las
autovías de los tramos desdoblados de las nacionales recibían la
nomenclatura de la misma nacional que desdoblaban y si fuere el caso ahora
no habría ningún problema en poner unas de motorway, porque cumplían esos
criterios , otras de trunk y otras de primary, porque no llegan para más,
porque ahora no las pueden ni usar los camiones, que lo tienen prohibido y
los desvían por la AP-7.
Alguien dirá...ya, pero es que es la carretera de la 

Re: [Talk-GB] Addressing of flats: review best practice

[Anton Klim]

I was under the impression entrance nodes is the only place to put addr:flats? 
In the absence of entrance nodes, of course, it makes sense to tag the outline, 
but some apartment blocks might have weird layouts where you can’t do that.
Would building:part solve your problem?

Ant

> 18 апр. 2018 г., в 12:03, Derick Rethans :
> 
>> On Tue, 17 Apr 2018, Andrew Hain wrote:
>> 
>> I have been mapping a complex of flats that consists of a series of 
>> blocks each with its own entrance, tagging each section with 
>> addr:housename and addr:flats 
>> [https://www.openstreetmap.org/way/580234651]. The standard layer 
>> repeats the name of the whole block for each section, which I find a 
>> bit clunky (Humanitarian doesn’t label anything at all). Before I 
>> discuss this with the map renderers, am I doing the best thing for 
>> tagging?
> 
> Yes, I think so. I have a similar situation here:
> https://www.openstreetmap.org/#map=19/51.53422/-0.19844
> 
> Although I mapped the whole building there with its name, and then each 
> entrance separately as I don't know where the sections are exactly.
> 
> I wrote a style change some time ago too: 
> https://derickrethans.nl/flats.html — but nothing on that front has 
> improved yet :-/
> 
> I wish it would render similarly to 
> https://www.openstreetmap.org/way/282084602#map=19/51.52662/-0.18901=D 
> perhaps :-/
> 
> cheers,
> Derick
> 
> -- 
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
> or become my Patron: https://www.patreon.com/derickr
> twitter: @derickr and @xdebug
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [OSM-talk-be] Nodes or areas to tag amenities

[marc marc]

@ubipo for indoor=level, I suppose you mean indoor=yes indoor=thenumber :)

building:part is for a part of a building where tag related to the 
building itself doesn't have the same value for one part <> another part
for exemple a building that have one part with one level :
building:part=yes
building:levels=1
and another part with 2 levels
building:part=yes
building:levels=1
both parts make one building with building=yes on the outline

but inside a buidling, room nearly never affect the building "external look"
so it should not be any building:part tag on a room,
except if a building:part is made by only one room of course.

for room=restaurant on amenety=restaurant, I've been talking with 
PanierAvide who add this to the wiki. he agree that this is not good.
we are working on on howto make it better.

Le 18. 04. 18 à 18:43, Pieter Vander Vennet a écrit :
> I have some experience with indoor mapping.
> 
> I would invite you guys to have a look at my work of the Blekerij in 
> Gent 
> ,
>  
> as example. Toilets can be mapped as either a point or area with 
> 'amenity=toilets, indoor=yes; level=0' (or perhaps 'level=0-2', e.g. for 
> a building with toilets on the same location on floors 0 till 2.). Note 
> that 'level=0' is the ground floor (gelijkvloers).
> 
> I have no experience with the building:part=yes. I assume that 
> indoor=yes implies 'building:part=yes' and that 'building:part' is 
> rather used for roofs etc...
> 
> 
> 
> 
> Met vriendelijke groeten,
> Pieter Vander Vennet
> 
> 2018-04-18 18:13 GMT+02:00 joost schouppe  >:
> 
> How does this relate to the building:part=yes strategy that
> L'imaginaire has been playing with, e.g.
> https://www.openstreetmap.org/way/283645760
> 
> 
> 2018-04-18 15:56 GMT+02:00 Ubipo .  >:
> 
> After furter consideration I think indoor=level combined with
> amenity=restaurant should solve most problems.
> Improving the map would then be as simple as not editing the
> general indoor=level and just drawing new ways for individual
> rooms (not tagged amenity=restaurant).
> 
> A restaurant on multiple floors would indeed be tricky as
> indoor=level implies a single level, although I think just
> adding level=0;1 shouldn't be that bad, right?
> 
> On 18 April 2018 at 13:58, Marc Gemis  > wrote:
> 
> how does someone "improve" your mapping to add a separate
> area for
> room=toilets ? nested room areas ? split it off ?
> 
> m.
> 
> On Wed, Apr 18, 2018 at 12:43 PM, Ubipo .
> > wrote:
>  > Regarding the housenumbers: street and number is as said
> probably not needed
>  > and better reserved for the actual building, although a
> specialised
>  > addr:addition=a could be useful for the rooms.
>  > Regarding room=restaurant, I think that tag is perfectly
> fine. It just
>  > indicates the restaurant in it's entirety, with dining
> room, kitchen etc.
>  >
>  > On Wed, Apr 18, 2018, 12:10 marc marc
>  > wrote:
>  >>
>  >> for the addr : it look like strange that the room is in
> a building that
>  >> doesn't have the same addr:housenumber as the building.
>  >>
>  >> for multiple floors poi, you can draw all room with
> level=* tag
>  >> or as a first step only use indoor=yes for the whole area
>  >>
>  >> room=restaurant look like also strange for me.
>  >> a restaurant is several room=* item : kitchen, dining
> room, toilets,
>  >> cloakroom
>  >> so what's a room=restaurant ? it can not be the same as
> the area used
>  >> for amenity=restaurant. maybe it should be the area for
> the dining room.
>  >> the wiki advice to put both tag to the same polygon look
> like wrong.
>  >>
>  >>
>  >> Le 18. 04. 18 à 11:56, Marc Gemis a écrit :
>  >> > o, I forgot, what about a restaurant that occupies
> multiple floors ?
>  >> >
>  >> >
>  >> >
>  >> > On Wed, Apr 18, 2018 at 11:55 AM, Marc Gemis
> >
>  >> > wrote:
>  >> >> The idea of using 

[OSM-ja] 高速道路の定義について

[kkondo]

こんにちは
改名したxyzxyz2です。

現行通りにの下記の考え方（選択枝）も十分妥当性もあるようにも思います。
（価値観にも依存し私自身の意見は固まらないので申し訳ありません）

(1)「highway=motorway(_link) は現行定義通り自動車専用道路とする」

> (3) なお「自動車専用道路」は下記を指すと思います。
>- 高速自動車国道や一般国道自動車専用道路の自動車専用道路
>- 都市高速道路などの自動車専用道路
>- 道路法に基づく自動車専用道路
>- その他の自動車専用道路（これらの道路： https://ja.wikipedia.org/wiki/その他の自動車専用道路一覧 
> 
>  の多くも道路法に基づいているような気もしますが）



(2) ナンバリングを ref（道路番号）タグに付ける。


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

Re: [OSM-talk-be] Nodes or areas to tag amenities

[Pieter Vander Vennet]

I have some experience with indoor mapping.

I would invite you guys to have a look at my work of the Blekerij in Gent
,
as example. Toilets can be mapped as either a point or area with
'amenity=toilets, indoor=yes; level=0' (or perhaps 'level=0-2', e.g. for a
building with toilets on the same location on floors 0 till 2.). Note that
'level=0' is the ground floor (gelijkvloers).

I have no experience with the building:part=yes. I assume that indoor=yes
implies 'building:part=yes' and that 'building:part' is rather used for
roofs etc...




Met vriendelijke groeten,
Pieter Vander Vennet

2018-04-18 18:13 GMT+02:00 joost schouppe :

> How does this relate to the building:part=yes strategy that L'imaginaire
> has been playing with, e.g. https://www.openstreetmap.org/way/283645760
>
> 2018-04-18 15:56 GMT+02:00 Ubipo . :
>
>> After furter consideration I think indoor=level combined with
>> amenity=restaurant should solve most problems.
>> Improving the map would then be as simple as not editing the general
>> indoor=level and just drawing new ways for individual rooms (not tagged
>> amenity=restaurant).
>>
>> A restaurant on multiple floors would indeed be tricky as indoor=level
>> implies a single level, although I think just adding level=0;1 shouldn't be
>> that bad, right?
>>
>> On 18 April 2018 at 13:58, Marc Gemis  wrote:
>>
>>> how does someone "improve" your mapping to add a separate area for
>>> room=toilets ? nested room areas ? split it off ?
>>>
>>> m.
>>>
>>> On Wed, Apr 18, 2018 at 12:43 PM, Ubipo . 
>>> wrote:
>>> > Regarding the housenumbers: street and number is as said probably not
>>> needed
>>> > and better reserved for the actual building, although a specialised
>>> > addr:addition=a could be useful for the rooms.
>>> > Regarding room=restaurant, I think that tag is perfectly fine. It just
>>> > indicates the restaurant in it's entirety, with dining room, kitchen
>>> etc.
>>> >
>>> > On Wed, Apr 18, 2018, 12:10 marc marc 
>>> wrote:
>>> >>
>>> >> for the addr : it look like strange that the room is in a building
>>> that
>>> >> doesn't have the same addr:housenumber as the building.
>>> >>
>>> >> for multiple floors poi, you can draw all room with level=* tag
>>> >> or as a first step only use indoor=yes for the whole area
>>> >>
>>> >> room=restaurant look like also strange for me.
>>> >> a restaurant is several room=* item : kitchen, dining room, toilets,
>>> >> cloakroom
>>> >> so what's a room=restaurant ? it can not be the same as the area used
>>> >> for amenity=restaurant. maybe it should be the area for the dining
>>> room.
>>> >> the wiki advice to put both tag to the same polygon look like wrong.
>>> >>
>>> >>
>>> >> Le 18. 04. 18 à 11:56, Marc Gemis a écrit :
>>> >> > o, I forgot, what about a restaurant that occupies multiple floors ?
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Wed, Apr 18, 2018 at 11:55 AM, Marc Gemis 
>>> >> > wrote:
>>> >> >> The idea of using indoor mapping is good, and it's probably the
>>> future
>>> >> >> to solve all the problems you mention. (we had a similar discussion
>>> >> >> last Friday on the Riot channel)
>>> >> >>
>>> >> >> Some remarks:
>>> >> >>
>>> >> >> - does it make sense for a "room" to have an house number and a
>>> street
>>> >> >> ? I would expect those on the building, and floor or level or so on
>>> >> >> the room.
>>> >> >> - I'm not familiar enough with the simple  indoor tagging, but I
>>> would
>>> >> >> expect that a restaurant exists of multiple rooms (dining, toilets,
>>> >> >> kitchen) not just one.
>>> >> >> - On the Riot channel the entrance to the restaurant was also seen
>>> as
>>> >> >> important.
>>> >> >>
>>> >> >> m
>>> >> >>
>>> >> >> On Wed, Apr 18, 2018 at 10:06 AM, Ubipo . 
>>> >> >> wrote:
>>> >> >>> Everyone,
>>> >> >>>
>>> >> >>> A long standing question for osm mapping in cities is wether to
>>> tag
>>> >> >>> amenities in multi-purpose buildings as:
>>> >> >>> - a separate node inside the building's way
>>> >> >>> - the building itself, using both building=house and amenity=*
>>> (only
>>> >> >>> valid
>>> >> >>> with single-amenity buildings)
>>> >> >>> The node approach has consistency issues like these buildings:
>>> >> >>> https://www.openstreetmap.org/node/656793551 .
>>> >> >>>
>>> >> >>> The area approach is more consistent but doesn't really allow
>>> >> >>> multi-purpose
>>> >> >>> buildings.
>>> >> >>> A third, lesser used method is to use part of the simple indoor
>>> >> >>> tagging
>>> >> >>> schema. I've used a simplified version of this for this
>>> restaurant:
>>> >> >>> https://www.openstreetmap.org/way/580985564 .
>>> >> >>> This approach uses two overlapping ways, one for the general
>>> building
>>> >> >>> (tagged building=house) and one for the restaurant 

[OSM-ja] 高速道路の定義について

[kkondo]

こんにちは
改名したxyzxyz2です。議論が進んでいたのですね。

(1)「高速道路ナンバリング付きの道路を highway=motorway とする。」という選択枝に、下記の追加オプションもお願いできるでしょうか？
   - 追加 (1) ただし自動車専用道路に限る

   
上記の意図は、例えば、西九州自動車道（E35）の二丈浜玉道路（当面活用区間）は自動車専用ではないがナンバリング区間になっているようですが（はっきりそうかは不明）、highway=motorway
 とするかという問いです。

(2)「motorroad=yesの定義を「歩行者、軽車両通行止め」の道路とする。」という選択枝に、下記の追加オプションもお願いできるでしょうか？、
   - 追加 (1) highway=motorway(_link) 指定とは排他的にタグ付けする。
   - 追加 (2) 高架・トンネル・橋梁に限定した短い孤立区間は除く。

   
「motorroad=yesの定義を「歩行者、軽車両通行止め」の道路とする＋高架・トンネル・橋梁に限定した短い孤立区間は除く」という選択枝の意図は、現在、名豊道路などが
 highway=motorway 
とタグ付けされているのは、そのような考えもあるかと推測される。それらのような軽車両通行禁止（かつ高速道路にも繋がっている）の高規格道路を何か適切にタグ付けしたいならば、motorroad=yes
 のタグ付けが候補だろうかという問いです。

(3) なお軽車両通行可能な道路にもしも highway=motorway もしくは motorroad=yes 
が付けられることになるとやはり変だと思うのですがいかがでしょうか？

(3) なお「自動車専用道路」は下記を指すと思います。
   - 高速自動車国道や一般国道自動車専用道路の自動車専用道路
   - 都市高速道路などの自動車専用道路
   - 道路法に基づく自動車専用道路
   - その他の自動車専用道路（これらの道路： https://ja.wikipedia.org/wiki/その他の自動車専用道路一覧 

 の多くも道路法に基づいているような気もしますが）


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

Re: [Talk-es] Propuesta: cambiar la categoría de algunas carreteras nacionales en base a su uso y estado actuales.

[David Marín Carreño]

Las alternativas planteadas no son excluyentes.

La normalización actual se basa en el supuesto general de que existe una
asociación entre la categoría administrativa asignada a una vía y sus
características físicas mínimas generales. Esta normalización habitualmente
funciona. Podremos tener casos concretos en los que esto no es así, pero
creo que habría que examinar estos casos concretos porque pueden ser la
excepción a la norma.

Entiendo que YoPaseoPor está abogando por rebajar la categoría de algunas
carreteras nacionales de trunk a primary o secondary. Yo no estoy muy
convencido de esto. Yo, personalmente consideraría aumentar la categoría de
las carreteras autonómicas de doble sentido de primera categoría a trunk,
siempre siguiendo el mismo criterio dentro de cada comunidad autónoma, ya
que dichas vías suelen tener características físicas similares a las de una
carretera nacional, y no tienen una importancia menor (según tráfico
soportado).

Luego tenemos el caso aparte de ciertas comunidades autónomas que en su
regulación han decidido que distintos tramos de una carretera con una única
referencia tengan distinta importancia, mantenimiento y características
físicas. Considero que estos casos deberán examinarse autonomía por
autonomía y caso por caso, ya qu no son el caso habitual dentro de la
legislación autonómica existente.

Un cordial saludo,
--
David Marín Carreño


El mié., 18 abr. 2018 a las 18:11, Diego García ()
escribió:

> Sigue sin parecerme bien la propuesta.
>
> Pienso que el valor de la etiqueta highway debe estar referida a toda la
> vía, y que hace referencia al nivel de esa vía dentro de la red de vías, no
> a sus características físicas. Si se quieren mapear características físicas
> de la vía, que pueden cambiar (y de hecho cambian) a lo largo de su
> trazado, deben emplearse otras etiquetas: ancho de vía, número de carriles,
> velocidad máxima, presencia de arcén,...
>
> En cierto modo, cambiar el valor de la etiqueta highway atendiendo a
> criterios físicos, y además por tramos, para que trozos de vías trunk de
> peor estado no aparezcan al mismo nivel que otros, sería mapear para el
> render.
>
> Un cordial saludo,
>
> El dom., 15 abr. 2018 a las 10:52, yo paseopor ()
> escribió:
>
>> Al hilo de una "batalla" (en la que un usuario experimentado me insultó y
>> lo dejé por imposible) vuelvo a la carga con un tema simple: la necesidad
>> de que toda carretera no transferida y que dependa del Ministerio de
>> Fomento del Gobierno de España (nacional) no necesariamente haya de ser
>> trunk.
>>
>> Rationale
>>
>> Basta con mirar la wiki para darse cuenta de que la definición de trunk
>> no encaja con algunas carreteras nacionales en algunos de sus tramos.
>> Además , si miramos a nuestro entorno la cuestión ha cambiado algo desde
>> que lo hablamos la última vez, países que habían tenido todas sus
>> carreteras "Nacionales/Estatales/..." pintadas de rojo (el color de trunk
>> en OSMCarto) ya han distinguido básicamente entre aquellas que son
>> importantes de verdad (y que suelen estar desdobladas la gran mayoría) y
>> las que no.Si miramos a un zoom 7 no es que nuestros países vecinos se
>> hayan quedado vacíos e incomunicados de infraestructuras, es que el render
>> no muestra estas vías básicas pero no preferentes hasta el render 8 en que
>> además empiezan a mostrarse también las vías de ferrocarril y otras
>> infraestructuras básicas que del 8 hacia atrás no salen.
>>
>> Mirando nuestro entorno vemos que:
>>
>> Portugal: La clasificación de vías se basa en itinerarios y no en las
>> Estradas Nacionais
>> Andorra: En Andorra no hay una sola carretera trunk ni siquiera que
>> enlace desde otros países...bueno, sí, hay una , adivinad de qué país viene.
>> Francia: Hay Routes Nacionales que no lo son.
>> Bélgica: No todas las N guardan la misma categoría
>> Holanda: Igual caso en Holanda
>> Austria: En Austria las B , las que van después de las A, no acostumbran
>> a ser trunk.
>> Alemania: Mirando un poco por encima veo que las que son trunk son
>> aquellas que son autovías.
>> Italia: Solo algunas Stradas Stradales son trunk (aún a riesgo de dejarte
>> en sus baches las ruedas)
>> Suiza: Carreteras principales como la 1 , que atraviesa el país de punta
>> a punta no son trunk y el único motivo en general por el que pasarías por
>> ellas es para saltarte la viñeta (el impuesto que se paga por acceder a las
>> autopistas.)
>> Reino Unido: No todas las A son trunk, como tampoco todas sus autovías
>> merecieran llamarse así (con semáforos, con rotondas...)
>>
>> -Tiene sentido también, la gran mayoría de autovías en nuestro país se
>> han hecho resiguiendo recorridos de muchas nacionales, cuando no
>> desdoblando la misma nacional haciendo desaparecer su trazado original.
>> -De igual manera ya hace años por suerte que las vías importantes de cada
>> comunidad autónoma que cumplen ciertos requisitos de preferencia (suelen
>> ser vías 

Re: [OSM-talk-be] Nodes or areas to tag amenities

[joost schouppe]

How does this relate to the building:part=yes strategy that L'imaginaire
has been playing with, e.g. https://www.openstreetmap.org/way/283645760

2018-04-18 15:56 GMT+02:00 Ubipo . :

> After furter consideration I think indoor=level combined with
> amenity=restaurant should solve most problems.
> Improving the map would then be as simple as not editing the general
> indoor=level and just drawing new ways for individual rooms (not tagged
> amenity=restaurant).
>
> A restaurant on multiple floors would indeed be tricky as indoor=level
> implies a single level, although I think just adding level=0;1 shouldn't be
> that bad, right?
>
> On 18 April 2018 at 13:58, Marc Gemis  wrote:
>
>> how does someone "improve" your mapping to add a separate area for
>> room=toilets ? nested room areas ? split it off ?
>>
>> m.
>>
>> On Wed, Apr 18, 2018 at 12:43 PM, Ubipo .  wrote:
>> > Regarding the housenumbers: street and number is as said probably not
>> needed
>> > and better reserved for the actual building, although a specialised
>> > addr:addition=a could be useful for the rooms.
>> > Regarding room=restaurant, I think that tag is perfectly fine. It just
>> > indicates the restaurant in it's entirety, with dining room, kitchen
>> etc.
>> >
>> > On Wed, Apr 18, 2018, 12:10 marc marc 
>> wrote:
>> >>
>> >> for the addr : it look like strange that the room is in a building that
>> >> doesn't have the same addr:housenumber as the building.
>> >>
>> >> for multiple floors poi, you can draw all room with level=* tag
>> >> or as a first step only use indoor=yes for the whole area
>> >>
>> >> room=restaurant look like also strange for me.
>> >> a restaurant is several room=* item : kitchen, dining room, toilets,
>> >> cloakroom
>> >> so what's a room=restaurant ? it can not be the same as the area used
>> >> for amenity=restaurant. maybe it should be the area for the dining
>> room.
>> >> the wiki advice to put both tag to the same polygon look like wrong.
>> >>
>> >>
>> >> Le 18. 04. 18 à 11:56, Marc Gemis a écrit :
>> >> > o, I forgot, what about a restaurant that occupies multiple floors ?
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Apr 18, 2018 at 11:55 AM, Marc Gemis 
>> >> > wrote:
>> >> >> The idea of using indoor mapping is good, and it's probably the
>> future
>> >> >> to solve all the problems you mention. (we had a similar discussion
>> >> >> last Friday on the Riot channel)
>> >> >>
>> >> >> Some remarks:
>> >> >>
>> >> >> - does it make sense for a "room" to have an house number and a
>> street
>> >> >> ? I would expect those on the building, and floor or level or so on
>> >> >> the room.
>> >> >> - I'm not familiar enough with the simple  indoor tagging, but I
>> would
>> >> >> expect that a restaurant exists of multiple rooms (dining, toilets,
>> >> >> kitchen) not just one.
>> >> >> - On the Riot channel the entrance to the restaurant was also seen
>> as
>> >> >> important.
>> >> >>
>> >> >> m
>> >> >>
>> >> >> On Wed, Apr 18, 2018 at 10:06 AM, Ubipo . 
>> >> >> wrote:
>> >> >>> Everyone,
>> >> >>>
>> >> >>> A long standing question for osm mapping in cities is wether to tag
>> >> >>> amenities in multi-purpose buildings as:
>> >> >>> - a separate node inside the building's way
>> >> >>> - the building itself, using both building=house and amenity=*
>> (only
>> >> >>> valid
>> >> >>> with single-amenity buildings)
>> >> >>> The node approach has consistency issues like these buildings:
>> >> >>> https://www.openstreetmap.org/node/656793551 .
>> >> >>>
>> >> >>> The area approach is more consistent but doesn't really allow
>> >> >>> multi-purpose
>> >> >>> buildings.
>> >> >>> A third, lesser used method is to use part of the simple indoor
>> >> >>> tagging
>> >> >>> schema. I've used a simplified version of this for this restaurant:
>> >> >>> https://www.openstreetmap.org/way/580985564 .
>> >> >>> This approach uses two overlapping ways, one for the general
>> building
>> >> >>> (tagged building=house) and one for the restaurant on the ground
>> floor
>> >> >>> (tagged room=restaurant and of course amenity=restaurant).
>> >> >>>
>> >> >>> Drawbacks of this are for one that the two ways fully overlap. This
>> >> >>> triggers
>> >> >>> the JOSM validator and probably some QC tools. Secondly renderers
>> >> >>> might have
>> >> >>> trouble placing the icons and house numbers of multiple areas like
>> >> >>> this.
>> >> >>> Luckily both these problems could be fixed. The positives are of
>> >> >>> course:
>> >> >>> consistency and the possibility for multiple amenities (using the
>> >> >>> level=*
>> >> >>> key).
>> >> >>>
>> >> >>> What do you all think of this approach?
>> >> >>>
>> >> >>> Kind regards,
>> >> >>> Pieter (Ubipo)
>> >> >>>
>> >> >>> ___
>> >> >>> Talk-be mailing list
>> >> >>> Talk-be@openstreetmap.org
>> >> >>> 

Re: [Talk-es] Propuesta: cambiar la categoría de algunas carreteras nacionales en base a su uso y estado actuales.

[Diego García]

Sigue sin parecerme bien la propuesta.

Pienso que el valor de la etiqueta highway debe estar referida a toda la
vía, y que hace referencia al nivel de esa vía dentro de la red de vías, no
a sus características físicas. Si se quieren mapear características físicas
de la vía, que pueden cambiar (y de hecho cambian) a lo largo de su
trazado, deben emplearse otras etiquetas: ancho de vía, número de carriles,
velocidad máxima, presencia de arcén,...

En cierto modo, cambiar el valor de la etiqueta highway atendiendo a
criterios físicos, y además por tramos, para que trozos de vías trunk de
peor estado no aparezcan al mismo nivel que otros, sería mapear para el
render.

Un cordial saludo,

El dom., 15 abr. 2018 a las 10:52, yo paseopor ()
escribió:

> Al hilo de una "batalla" (en la que un usuario experimentado me insultó y
> lo dejé por imposible) vuelvo a la carga con un tema simple: la necesidad
> de que toda carretera no transferida y que dependa del Ministerio de
> Fomento del Gobierno de España (nacional) no necesariamente haya de ser
> trunk.
>
> Rationale
>
> Basta con mirar la wiki para darse cuenta de que la definición de trunk no
> encaja con algunas carreteras nacionales en algunos de sus tramos. Además ,
> si miramos a nuestro entorno la cuestión ha cambiado algo desde que lo
> hablamos la última vez, países que habían tenido todas sus carreteras
> "Nacionales/Estatales/..." pintadas de rojo (el color de trunk en OSMCarto)
> ya han distinguido básicamente entre aquellas que son importantes de verdad
> (y que suelen estar desdobladas la gran mayoría) y las que no.Si miramos a
> un zoom 7 no es que nuestros países vecinos se hayan quedado vacíos e
> incomunicados de infraestructuras, es que el render no muestra estas vías
> básicas pero no preferentes hasta el render 8 en que además empiezan a
> mostrarse también las vías de ferrocarril y otras infraestructuras básicas
> que del 8 hacia atrás no salen.
>
> Mirando nuestro entorno vemos que:
>
> Portugal: La clasificación de vías se basa en itinerarios y no en las
> Estradas Nacionais
> Andorra: En Andorra no hay una sola carretera trunk ni siquiera que enlace
> desde otros países...bueno, sí, hay una , adivinad de qué país viene.
> Francia: Hay Routes Nacionales que no lo son.
> Bélgica: No todas las N guardan la misma categoría
> Holanda: Igual caso en Holanda
> Austria: En Austria las B , las que van después de las A, no acostumbran a
> ser trunk.
> Alemania: Mirando un poco por encima veo que las que son trunk son
> aquellas que son autovías.
> Italia: Solo algunas Stradas Stradales son trunk (aún a riesgo de dejarte
> en sus baches las ruedas)
> Suiza: Carreteras principales como la 1 , que atraviesa el país de punta a
> punta no son trunk y el único motivo en general por el que pasarías por
> ellas es para saltarte la viñeta (el impuesto que se paga por acceder a las
> autopistas.)
> Reino Unido: No todas las A son trunk, como tampoco todas sus autovías
> merecieran llamarse así (con semáforos, con rotondas...)
>
> -Tiene sentido también, la gran mayoría de autovías en nuestro país se han
> hecho resiguiendo recorridos de muchas nacionales, cuando no desdoblando la
> misma nacional haciendo desaparecer su trazado original.
> -De igual manera ya hace años por suerte que las vías importantes de cada
> comunidad autónoma que cumplen ciertos requisitos de preferencia (suelen
> ser vías nuevas,fuertes inversiones hechas por estas, sin cruces a nivel,
> con una velocidad que oscila entre los 80 y los 100 km/h y que suelen tener
> un mantenimiento óptimo) ya son consideradas trunk por el mapa y la
> comunidad. ¿Entonces por qué una vía que no cumple con esos mismos
> requisitos debe ser considerada trunk? ¿Simplemente por pertenecer a una
> administración u otra? Aunque suene raro estos días recordemos que todas
> las administraciones son estado (las comunidades autónomas gozan de
> estatutos de autonomía aprobados en el Congreso de los Diputados con rango
> de Ley Orgánica y sancionados por el rey). Por lo que este hecho no debería
> ser significativo para que una vía gozara en el mapa de más o menos
> visibilidad sino que habría que seguir otros criterios más acordes con la
> conducción y el transporte.
>
> -A riesgo de lo antiestético que pueda ser que el mapa quede a trozos...
> ¿es que un buen ruteador no sabe distinguir más allá de la categoría de la
> carretera? ¿Es que nos vamos a fijar en la estética? ¿Es que eso no sería
> mapear para el render? ¿En los otros países en los que eso pasa hay
> problemas para usar navegadores GPS?
>
> -También a riesgo de considerar algunos determinados ejes como de suma
> importancia por el "simple" hecho de reseeguir determinado accidente
> geográfico pensemos en si gozan al lado de una vía alternativa ,aunque esta
> sea de pago (sigue siendo una vía alternativa , y de hecho hoy en día en
> muchas de estas vías hay acuerdos para desviar el tráfico pesado por o que
> su importancia ha 

Re: [OSM-ja] 高速道路の定義について

[Ras and Road]

Ras and Roadです。

hayashiさんのコメントに丁寧にレスポンスしたいところですが、ちょっと時間がかかりそう（もしかするとタイムアウトするかも）なので、いま申したいこと2点だけを投稿します。

> 今回のように急に賛否の決を取られたら、
「ちょっと待ってください、私の質問への回答がまだなので時期尚早」でいいのではないですか？
「私の発言をすべて無視して強行採決」という表現は、ちょっと棘棘しい印象を持ちました。

> 「OSMはon the groundを重視する」
そのとおりです。しかし、他者のマッピングが疑わしいときでもサーベイするしか手がないのはしんどいな、と。それが500km離れた場所だったら。マッピングした人はタグを正しく理解していて現地標示を確認したと信じるべきか。
道路種別を変更するときにはエビデンスをMapillayにアップせよと言うわけにはいかないですし、Mapillayにアップされている日本の情報は残念ながらカバー率がまだまだ低いですし。
重ねての弁明ですが、机上での検証可能性が担保されていることを条件に賛否判断することを示唆する意思はありません。

# 
脱線ですが、県道経路の確認はめちゃくちゃしんどいです。都道府県例規集を見てもよくわからず、法務局で土地所有者を照会する資金力はなく、現地に県道標識が設置されていないことも多く、已む無くサーベイして、側溝のフタに刻まれた県章で県道であることを確信する等。
# その一方で、現地の標示が絶対というわけではないのが日本の困りゴト。はるか昔に指定から外された国道や県道の旧道に残っている標識を訪ね歩く趣味もありまして。

** Ras and Road **
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-it] Sundial Atlas Mobile

[Martin Koppenhoefer]

sent from a phone

> On 18. Apr 2018, at 17:27, Lorenzo Pesci  
> wrote:
> 
> Se così fosse non ci sono molte speranza che altri siti 
> (p.es. ne conosco uno che recensisce tutte le chiese o edifici di pregio nel 
> centro Italia, usando sempre Gmaps)
> passino ad usate Osm che, nonostante  la nostra buona volontà, rimane secondo 
> me troppo di nicchia



volendo si possono integrare le mappe (tiles) di osm anche con le API di google 
maps. 

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

[Talk-it] Sundial Atlas Mobile

[Lorenzo Pesci]

Salve, ho installato sul cell. l'applicazione Sundial Atlas Mobile
che consente di localizzare tantissime meridiane.

Sul sito di Osm  non vengono neanche visualizzate.

Lo sfondo che viene usato è quello di Google e quando ho proposto allo 
sviluppatore l'uso di Osm la risposta è stata questa:

" E' vero, sarebbe bello... ma con le mappe di Google posso usare una 
interfaccia semplice per creare la mappa, zoommarla, rispondere ad ogni evento 
ecc. mentre con le Open Street Map dovrei partire da zero... mi dispiace ma non 
me la sento di affrontare un lavoro così pesante :-)  "

Se così fosse non ci sono molte speranza che altri siti 
(p.es. ne conosco uno che recensisce tutte le chiese o edifici di pregio nel 
centro Italia, usando sempre Gmaps)
passino ad usate Osm che, nonostante  la nostra buona volontà, rimane secondo 
me troppo di nicchia.

Saluti Lorenzo Pesci


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

Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, Hilfsorganisationen

[Daniel Korn]

Du hast recht, da habe ich wohl einen falsch angefasst gehabt. Ist 
korrigiert [1].


[1] https://www.openstreetmap.org/changeset/58204999

Am 18.04.2018 um 17:10 schrieb Scholtes, Martin:

Naja da warst du vllt etwas zu schnell oder gilt way 116174430 nicht als 
rettungswache?
Vllt eine genauere Einzelfallprüfung statt rundum Schlag.

Gruß Martin
Von meinem Huawei-Mobiltelefon gesendet

 Originalnachricht 
Betreff: Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, 
Hilfsorganisationen
Von: Daniel Korn 
An: talk-de@openstreetmap.org
Cc:


Ich habe in Deutschland die Rettungswachen von den Bergwachten nun
differenziert [1, 2].

Gruß
Daniel

[1] https://www.openstreetmap.org/changeset/58204411
[2] http://overpass-turbo.eu/s/y14

Am 18.04.2018 um 13:38 schrieb Tom Pfeifer:

Das Taggen der Hilfsorganisationen ist recht chaotisch, daher ist ja
seit langem der "Emergency-cleanup" im Wiki annonciert, wird aber nur
halbherzig betrieben.

Für die Bergrettung würde sich "emergency=mountain_rescue" anbieten,
bisher 2 Verwendungen.

Für den Zivilschutz hatte ein Australier mal "emergency=ses_station"
etabliert, was wegen des nationalen Acronyms SES ungeeignet ist [1].

Bei den Diskussionen dort, ob emergency=disaster_response geeignet
wäre, stieß ich auf die derzeitige Verwendung beim deutschen
Technischen Hilfswerk (THW) nach dem Schema amenity=emergency_service
+ emergency_service=technical, was einem Proposal von 2008 [2] folgt.

[1] https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dses_station
[2]
https://wiki.openstreetmap.org/wiki/Proposed_features/Emergency_service

Tom

On 15.04.2018 14:04, Lena Essig wrote:

Hallo zusammen,

mir ist aufgefallen, dass bei der Suche nach
"emergency"="ambulance_station"
nicht nur Rettungswachen angezeigt werden, sondern auch Bergwachten oder
auch Ortsvereine.
Nur sehr wenige der Bergwachten sind mit "amenity"="mountain_rescue"
getaggt.
Da Bergwachten nur besondere Einsatzarten übernehmen, sollten sie von
normalen Rettungswachen unterschieden werden. Ebenso Ortsvereine der
einzelnen Hilfsorganisationen, da sie nichts mit dem Rettungsdienst
zu tun
haben.
Wie ist denn die allgemeine Regelung für Orstvereine oder
Katastrophenschutzzentren?


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


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



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

Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, Hilfsorganisationen

[Scholtes, Martin]

Naja da warst du vllt etwas zu schnell oder gilt way 116174430 nicht als 
rettungswache?
Vllt eine genauere Einzelfallprüfung statt rundum Schlag.

Gruß Martin
Von meinem Huawei-Mobiltelefon gesendet

 Originalnachricht 
Betreff: Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, 
Hilfsorganisationen
Von: Daniel Korn 
An: talk-de@openstreetmap.org
Cc:


Ich habe in Deutschland die Rettungswachen von den Bergwachten nun 
differenziert [1, 2].

Gruß
Daniel

[1] https://www.openstreetmap.org/changeset/58204411
[2] http://overpass-turbo.eu/s/y14

Am 18.04.2018 um 13:38 schrieb Tom Pfeifer:
> Das Taggen der Hilfsorganisationen ist recht chaotisch, daher ist ja 
> seit langem der "Emergency-cleanup" im Wiki annonciert, wird aber nur 
> halbherzig betrieben.
>
> Für die Bergrettung würde sich "emergency=mountain_rescue" anbieten, 
> bisher 2 Verwendungen.
>
> Für den Zivilschutz hatte ein Australier mal "emergency=ses_station" 
> etabliert, was wegen des nationalen Acronyms SES ungeeignet ist [1].
>
> Bei den Diskussionen dort, ob emergency=disaster_response geeignet 
> wäre, stieß ich auf die derzeitige Verwendung beim deutschen 
> Technischen Hilfswerk (THW) nach dem Schema amenity=emergency_service 
> + emergency_service=technical, was einem Proposal von 2008 [2] folgt.
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dses_station
> [2] 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Emergency_service
>
> Tom
>
> On 15.04.2018 14:04, Lena Essig wrote:
>> Hallo zusammen,
>>
>> mir ist aufgefallen, dass bei der Suche nach 
>> "emergency"="ambulance_station"
>> nicht nur Rettungswachen angezeigt werden, sondern auch Bergwachten oder
>> auch Ortsvereine.
>> Nur sehr wenige der Bergwachten sind mit "amenity"="mountain_rescue"
>> getaggt.
>> Da Bergwachten nur besondere Einsatzarten übernehmen, sollten sie von
>> normalen Rettungswachen unterschieden werden. Ebenso Ortsvereine der
>> einzelnen Hilfsorganisationen, da sie nichts mit dem Rettungsdienst 
>> zu tun
>> haben.
>> Wie ist denn die allgemeine Regelung für Orstvereine oder
>> Katastrophenschutzzentren?
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de


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

Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, Hilfsorganisationen

[Daniel Korn]

Ich habe in Deutschland die Rettungswachen von den Bergwachten nun 
differenziert [1, 2].


Gruß
Daniel

[1] https://www.openstreetmap.org/changeset/58204411
[2] http://overpass-turbo.eu/s/y14

Am 18.04.2018 um 13:38 schrieb Tom Pfeifer:
Das Taggen der Hilfsorganisationen ist recht chaotisch, daher ist ja 
seit langem der "Emergency-cleanup" im Wiki annonciert, wird aber nur 
halbherzig betrieben.


Für die Bergrettung würde sich "emergency=mountain_rescue" anbieten, 
bisher 2 Verwendungen.


Für den Zivilschutz hatte ein Australier mal "emergency=ses_station" 
etabliert, was wegen des nationalen Acronyms SES ungeeignet ist [1].


Bei den Diskussionen dort, ob emergency=disaster_response geeignet 
wäre, stieß ich auf die derzeitige Verwendung beim deutschen 
Technischen Hilfswerk (THW) nach dem Schema amenity=emergency_service 
+ emergency_service=technical, was einem Proposal von 2008 [2] folgt.


[1] https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dses_station
[2] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Emergency_service


Tom

On 15.04.2018 14:04, Lena Essig wrote:

Hallo zusammen,

mir ist aufgefallen, dass bei der Suche nach 
"emergency"="ambulance_station"

nicht nur Rettungswachen angezeigt werden, sondern auch Bergwachten oder
auch Ortsvereine.
Nur sehr wenige der Bergwachten sind mit "amenity"="mountain_rescue"
getaggt.
Da Bergwachten nur besondere Einsatzarten übernehmen, sollten sie von
normalen Rettungswachen unterschieden werden. Ebenso Ortsvereine der
einzelnen Hilfsorganisationen, da sie nichts mit dem Rettungsdienst 
zu tun

haben.
Wie ist denn die allgemeine Regelung für Orstvereine oder
Katastrophenschutzzentren?



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



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

Re: [OSM-talk-be] Nodes or areas to tag amenities

[Ubipo .]

After furter consideration I think indoor=level combined with
amenity=restaurant should solve most problems.
Improving the map would then be as simple as not editing the general
indoor=level and just drawing new ways for individual rooms (not tagged
amenity=restaurant).

A restaurant on multiple floors would indeed be tricky as indoor=level
implies a single level, although I think just adding level=0;1 shouldn't be
that bad, right?

On 18 April 2018 at 13:58, Marc Gemis  wrote:

> how does someone "improve" your mapping to add a separate area for
> room=toilets ? nested room areas ? split it off ?
>
> m.
>
> On Wed, Apr 18, 2018 at 12:43 PM, Ubipo .  wrote:
> > Regarding the housenumbers: street and number is as said probably not
> needed
> > and better reserved for the actual building, although a specialised
> > addr:addition=a could be useful for the rooms.
> > Regarding room=restaurant, I think that tag is perfectly fine. It just
> > indicates the restaurant in it's entirety, with dining room, kitchen etc.
> >
> > On Wed, Apr 18, 2018, 12:10 marc marc  wrote:
> >>
> >> for the addr : it look like strange that the room is in a building that
> >> doesn't have the same addr:housenumber as the building.
> >>
> >> for multiple floors poi, you can draw all room with level=* tag
> >> or as a first step only use indoor=yes for the whole area
> >>
> >> room=restaurant look like also strange for me.
> >> a restaurant is several room=* item : kitchen, dining room, toilets,
> >> cloakroom
> >> so what's a room=restaurant ? it can not be the same as the area used
> >> for amenity=restaurant. maybe it should be the area for the dining room.
> >> the wiki advice to put both tag to the same polygon look like wrong.
> >>
> >>
> >> Le 18. 04. 18 à 11:56, Marc Gemis a écrit :
> >> > o, I forgot, what about a restaurant that occupies multiple floors ?
> >> >
> >> >
> >> >
> >> > On Wed, Apr 18, 2018 at 11:55 AM, Marc Gemis 
> >> > wrote:
> >> >> The idea of using indoor mapping is good, and it's probably the
> future
> >> >> to solve all the problems you mention. (we had a similar discussion
> >> >> last Friday on the Riot channel)
> >> >>
> >> >> Some remarks:
> >> >>
> >> >> - does it make sense for a "room" to have an house number and a
> street
> >> >> ? I would expect those on the building, and floor or level or so on
> >> >> the room.
> >> >> - I'm not familiar enough with the simple  indoor tagging, but I
> would
> >> >> expect that a restaurant exists of multiple rooms (dining, toilets,
> >> >> kitchen) not just one.
> >> >> - On the Riot channel the entrance to the restaurant was also seen as
> >> >> important.
> >> >>
> >> >> m
> >> >>
> >> >> On Wed, Apr 18, 2018 at 10:06 AM, Ubipo . 
> >> >> wrote:
> >> >>> Everyone,
> >> >>>
> >> >>> A long standing question for osm mapping in cities is wether to tag
> >> >>> amenities in multi-purpose buildings as:
> >> >>> - a separate node inside the building's way
> >> >>> - the building itself, using both building=house and amenity=* (only
> >> >>> valid
> >> >>> with single-amenity buildings)
> >> >>> The node approach has consistency issues like these buildings:
> >> >>> https://www.openstreetmap.org/node/656793551 .
> >> >>>
> >> >>> The area approach is more consistent but doesn't really allow
> >> >>> multi-purpose
> >> >>> buildings.
> >> >>> A third, lesser used method is to use part of the simple indoor
> >> >>> tagging
> >> >>> schema. I've used a simplified version of this for this restaurant:
> >> >>> https://www.openstreetmap.org/way/580985564 .
> >> >>> This approach uses two overlapping ways, one for the general
> building
> >> >>> (tagged building=house) and one for the restaurant on the ground
> floor
> >> >>> (tagged room=restaurant and of course amenity=restaurant).
> >> >>>
> >> >>> Drawbacks of this are for one that the two ways fully overlap. This
> >> >>> triggers
> >> >>> the JOSM validator and probably some QC tools. Secondly renderers
> >> >>> might have
> >> >>> trouble placing the icons and house numbers of multiple areas like
> >> >>> this.
> >> >>> Luckily both these problems could be fixed. The positives are of
> >> >>> course:
> >> >>> consistency and the possibility for multiple amenities (using the
> >> >>> level=*
> >> >>> key).
> >> >>>
> >> >>> What do you all think of this approach?
> >> >>>
> >> >>> Kind regards,
> >> >>> Pieter (Ubipo)
> >> >>>
> >> >>> ___
> >> >>> 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
> >> 

Re: [OSM-ja] 高速道路の定義について

[yuu hayashi]

hayashiです

Ras and Road さん 22:09へのレスです

私のTalk-jaへの返信の出し方が悪くて議論の表示順序がちぐはぐになってしまったようです。
つい先程もまた変なスレの出し方をしてしまいました。お詫びいたします。

> 上記のことから、「自動車専用道路」は「国で最高品質の道路」とみなすことができるといえます。
についてですが、
３月３１日のmuramotoさんの問題点に対する反証です。

“品質(performance)"についてですが、いろいろな項目が“品質(performance)"に該当するとみます。
保全品質、MTTFとか安全品質とか可視性とか
決してひとつの特定の項目を指しているのではないとおもいます。（すくなくともISO-9001的にはそうです）
でも、道路のパフォーマンスといえば普通は「流量（キャパ）」が連想されます。
流量を上げるために、車線を増やす、速度を上げる、信号機などの阻害要因を排除する、独立線にする（一方通行、歩道を併設しない）などの施策が講じられます。「流量を上げる」ことは「交通の円滑化」を図ると同義とみなしてもいいでしょう。
ただし、「市街地の交通の円滑化」「特定の道路の区間内の交通円滑化/道路交通騒音により生じる障害の防止」という目的で指定されるのは「自動車専用道路」だけとは限りません。普通の一般国道だって計画当初の目的は同じです。
「品質」内容というよりも、程度の問題です。
「secondary」＜「primary」＜「trunk」＜「motorway」と「品質」が上がるように設定するということだと思います
現行では
「３桁以上の県道」＜「２桁以内の県道」＜「国道」＜「自動車専用道路」
に割り当てられています。
また、これらの割当は「品質」だけの基準で設定されるものではありません。ネットワーク性とか車両規制の有無も考慮して決められます。


「机上での検証可能性」についてですが、
muramotoさんの「OSMはon the groundを重視する」のとおり、muramotoさんは「重視する」と柔らかい表現をつかってますが、
この一文はけっこう奥が深くて重要です。OSMの根幹を形成する重要な理念なのです。
そのため、この議論の判断に「机上での・・・」が判断に加えられたとはしたくないのです。
OSMとはこういう”しばりプレー”だと思ってマッピングを楽しんでください。
それと、心配しなくとも「Mapillay」なら道路上の標識ぐらいなら机上で簡単に確認できます。


2018年4月17日 22:09 Ras and Road :

> Ras and Roadです。
>
> まずは、hayashiさんの4月15日01:32の投稿へのレスポンスです。
> hayashiさんが
> > 上記のことから、「自動車専用道路」は「国で最高品質の道路」とみなすことができるといえます。
> と言及されているのは *提案1 乃至は *提案1-1 についてですよね？
> *提案3-1 motorroad=yesの定義を「自動車専用道路」標識がついた道路とする
> の解釈に関して、「自動車専用道路の標識がなくとも『歩行者、軽車両、原付、小型二輪』が通行できなければ『自動車専用道路』とみなす」なら、
> 通行制限の結果に変わりがないので反対はしないのですが。
>
> あまのさんの3/29投稿のとおり、自動車専用道路は道路法第48条の2に定められるとおり、「市街地の交通の円滑化」「特定の道路の区間内の交通円滑化/
> 道路交通騒音により生じる障害の防止」という目的で指定されるものです。
> もしかすると、「国で最高品質の道路（原文：to identify the highest-performance roads within
> a territory）」の“品質(performance)”の理解がこのスレッドに参加している人の間ですれ違っているのでしょうか？
> 私は、国土骨格やネットワークや産業基盤に資するかどうかが“品質(performance)”だと理解しています。
>
>
> 次に、hayashiさん/muramotoさん両名へのレスポンスです。
> 私も机上での検証可能性が判断条件だとは思いません。しかし、机上で検証する方法がない・難しいことを理解したうえで賛否を取るべきと考えた次第です。
> マッパーがもっと増えれば、それぞれの得意地域（気軽に現調できる地域）でマッパー相互に検証できるでしょうが、まだそんな状態ではないと思います。
>
> ** Ras and Road **
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-es] [Catastro] 29900 Málaga

[dcapillae]

Hola, Alan.

El archivo no estaba disponible. Ha sido error mío, no había subido el
archivo correcto al repositorio. Ya está corregido. Deberías poder abrirlo
sin problemas. He probado en mi ordenador y parece que funciona.

También te puede interesar trabajar con el complemento que comentó Javier
[1]. Haciendo clic en la imagen de fondo, te muestra un enlace directo a la
foto de fachada del Catastro. Quizás te resulte más cómodo que a través del
archivo 'address.osm'.


[1]
http://gis.19327.n8.nabble.com/Complemento-JOSM-para-Servicios-Web-de-Catastro-tp5914903p5915336.html



--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [OSM-talk-fr] Liens vers communauté FR sur iD...

[PanierAvide]

Je pensais surtout aux liens vers les pages web, mais effectivement ça 
dépend de ce que l'on entend par canal de communication.


Adrien.

Le 18/04/2018 à 14:47, Christian Quest a écrit :


Il me semble que ce qui est visé, ce sont les canaux de communication 
en ligne et cette carte agrège plutôt les réunion physiques locales.


Ce sont les mailing list locales qu'il faudrait ajouter ou les 
sections locales de forum.openstreetmap.fr et avoir à chaque fois une 
géométrie correspondante.


Manque aussi les DOM, car la géométrie que j'ai utilisé c'est le 
polygone de geofabrik pour la métropole. A améliorer donc, mais au 
moins on a un début et de quoi itérer... :)




Le 18/04/2018 à 09:32, PanierAvide a écrit :

Bonjour,

Pour éviter les doublons d'infos, on ne peut pas se baser sur la 
carte des groupes locaux ?

http://umap.openstreetmap.fr/fr/map/groupes-locaux-openstreetmap_152488#6/46.392/1.714

Cordialement,

Adrien.

Le 18/04/2018 à 09:26, Christian Quest a écrit :
La dernière version d'iD (ou la prochaine) peut afficher des liens 
vers les canaux de communication de la communauté OSM après la 
sauvegarde de ses contributions.


Ces liens dépendent de la zone où l'on a contribué et sont donc bien 
adapté pour pousser les nouveaux contributeurs à se mettre en 
contact avec le reste de la communauté locale.


J'ai ajouté les liens vers les canaux d'OSM France sur le dépôt github :

https://github.com/osmlab/osm-community-index/pull/83

Il est possible de descendre à un niveau encore plus local...

Il faut quelques fichiers json:
- un geojson qui définit la zone géographique
- un json pour définir chaque lien (mailinglist, forum, twitter, etc)

Les libellés sont à mettre en anglais... pour la traduction, je 
pense que c'est dans le transiflex d'iD (pas super pratique de 
séparer, mais bon).


--
Christian Quest - OpenStreetMap France


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



--
PanierAvide
Géomaticien & développeur


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


--
Christian Quest - OpenStreetMap France


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



--
PanierAvide
Géomaticien & développeur

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

Re: [OSM-talk-fr] Liens vers communauté FR sur iD...

[Christian Quest]

Il me semble que ce qui est visé, ce sont les canaux de communication en 
ligne et cette carte agrège plutôt les réunion physiques locales.


Ce sont les mailing list locales qu'il faudrait ajouter ou les sections 
locales de forum.openstreetmap.fr et avoir à chaque fois une géométrie 
correspondante.


Manque aussi les DOM, car la géométrie que j'ai utilisé c'est le 
polygone de geofabrik pour la métropole. A améliorer donc, mais au moins 
on a un début et de quoi itérer... :)




Le 18/04/2018 à 09:32, PanierAvide a écrit :

Bonjour,

Pour éviter les doublons d'infos, on ne peut pas se baser sur la carte 
des groupes locaux ?

http://umap.openstreetmap.fr/fr/map/groupes-locaux-openstreetmap_152488#6/46.392/1.714

Cordialement,

Adrien.

Le 18/04/2018 à 09:26, Christian Quest a écrit :
La dernière version d'iD (ou la prochaine) peut afficher des liens 
vers les canaux de communication de la communauté OSM après la 
sauvegarde de ses contributions.


Ces liens dépendent de la zone où l'on a contribué et sont donc bien 
adapté pour pousser les nouveaux contributeurs à se mettre en contact 
avec le reste de la communauté locale.


J'ai ajouté les liens vers les canaux d'OSM France sur le dépôt github :

https://github.com/osmlab/osm-community-index/pull/83

Il est possible de descendre à un niveau encore plus local...

Il faut quelques fichiers json:
- un geojson qui définit la zone géographique
- un json pour définir chaque lien (mailinglist, forum, twitter, etc)

Les libellés sont à mettre en anglais... pour la traduction, je pense 
que c'est dans le transiflex d'iD (pas super pratique de séparer, 
mais bon).


--
Christian Quest - OpenStreetMap France


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



--
PanierAvide
Géomaticien & développeur


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


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-ja] 高速道路の定義について

[yuu hayashi]

2018年 3月 26日の投稿で
moterwayの改定に対して下記の質問を投げかけています。

「現行方式の問題点は何ですか？」

「どのような不都合が生じているのでしょうか？」

「改定方式ではどのようなメリットが生じるのでしょうか？」

「現行の「Relation:route」タグがあるのに改定が必要となる理由が説明されていません。」

「既に入力された「highway=moterway」はどうするのでしょうか？」

これに対して十分な時間があったにもかかわらず、回答がありません。

現行の JapanTagging の改定をやるなら、上に上げた点はすべてクリアにされていなければならないものです。

３月３１日の
https://lists.openstreetmap.org/pipermail/talk-ja/2018-March/010039.html
に対しては4月15日に反証を出しています。
また、3/31に提示されたのは現行の問題点についてだけであり、その他の項目（改定のメリットや影響範囲など）が一切説明されておらず
「改定の必要性」が全く感じられません。
しかし、3/31の状況ではまだ提案内容の受け付と取りまとめの段階なので、議論の段階に入ってから質問をしようと考え 反証的な意見は自粛していました。

「既に十分な議論がなされた」とみなすなら、
私の指摘した問題点はクリアにできないことが確定したということですね。
ということで、「提案１」は否決されたとみなします。

前回も書きましたが
muramotoさんに進行役をやってもらう前にLISTUPしていたのは、あくまでも「提案内容」「やりたいこと」「現行の問題点」の洗い出し、
いわば議論の目標設定の段階です。
提案が出揃ったところで「議題」に取り上げるものの選別をして、議論の順番なりやり方と議論の目標設定を行う。
議論が停滞するようなら（このスレの場合なら3/26の質問に対して未解答の項目があれば）回答を促すなどを行うのが進行役の役目ではないでしょうか？

「具体的に、どの議題についてまだ意見が出尽くしていないと考えられており、いつまでその時間が必要と思われるかご意見ください。」
とおっしゃいますが、どの提案が賛否を問える状態に達していると考えているのでしょうか？

提案１は質問に回答が得られていない状態
提案２は原案も提出されていない状態
提案３はまさに議論がこれから始まろうかとうい状態
提案４と５は、提案内容を確認して提案１と同様の項目をはっきりさせて議題として取り上げるかどうかの判断が必要な状態。

本来は3/26のような項目はすべてクリアしてからTalk-jaに議案を上げるものですが、
このスレの題名を見ればわかるように、スレ主さんは議論というより問題提起と反応を見るぐらいの気持ちでスレを立てたものだと思います。
議題がはっきり決まったなら、
提案１は廃案が決まったので考慮する必要はないとして、
提案２と提案３は「高速道路」とは直接関係ないので別スレッドに立てて議論するほうが良いでしょう。
提案４と提案５も内容によっては別スレッドにしたほうがいいかもしれません。

それとスケジュールのたてかたですが、参加者の生活も考慮してください。
通常、メーリングリストでの日程は２週間以上前に告示するのが常識です。大多数の人が週末に活動するので１アクションに土日を含めるのが最低限のスパンででしょう。逆に週末が忙しいという人もいるので、最低でも１週間の時間的猶予を与えるの必要があるかと思います。
発言する方もいろいろと調べものをしたり現地確認したりしてから発言しないとろくな意見が出てきません。
今日も強行採決に急かされてこのメールを急いで書いているので車両分類の作業に手がつけられないことになりそうです。

今回のように急に賛否の決を取られたら、いままでの私の発言をすべて無視して強行採決を実行されたと理解するより他にどのように理解すればいいのでしょうかね？


2018年4月17日 6:32 tomoya muramoto :

> ＞提案のリストアップが終わった途端に、議論もなしにいきなり投票はないでしょう。
>
> すでにみなさんの意見は数多くあがっており、それに対する反論の提出など、議論はすでに進んでおりました。
> その状況のもと、メールでのやり取りがしばらく止まったので、意見はほぼ出尽くしたと判断し、投票に入りました。
>
> 具体的に、どの議題についてまだ意見が出尽くしていないと考えられており、いつまでその時間が必要と思われるかご意見ください。
>
> ＞提案１と４については、以前に現行方式の問題点と変更による利点を提示していただくよう要望を出しましたがどなたからも回答がないため、
> 議論する必要性がないと判断しました。
> 提案１については現行方式の問題点を提示しております。問題点を解決することそのものが利点であると考えます。
> https://lists.openstreetmap.org/pipermail/talk-ja/2018-March/010039.html
>
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-es] [Catastro] 29900 Málaga

[alan_gr]

Hola Daniel,

Buen trabajo!

El archivo address.osm está disponible para esta tarea? No he conseguido
bajarlo.

Un saludo
Alan




--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [OSM-talk-be] Nodes or areas to tag amenities

[Marc Gemis]

how does someone "improve" your mapping to add a separate area for
room=toilets ? nested room areas ? split it off ?

m.

On Wed, Apr 18, 2018 at 12:43 PM, Ubipo .  wrote:
> Regarding the housenumbers: street and number is as said probably not needed
> and better reserved for the actual building, although a specialised
> addr:addition=a could be useful for the rooms.
> Regarding room=restaurant, I think that tag is perfectly fine. It just
> indicates the restaurant in it's entirety, with dining room, kitchen etc.
>
> On Wed, Apr 18, 2018, 12:10 marc marc  wrote:
>>
>> for the addr : it look like strange that the room is in a building that
>> doesn't have the same addr:housenumber as the building.
>>
>> for multiple floors poi, you can draw all room with level=* tag
>> or as a first step only use indoor=yes for the whole area
>>
>> room=restaurant look like also strange for me.
>> a restaurant is several room=* item : kitchen, dining room, toilets,
>> cloakroom
>> so what's a room=restaurant ? it can not be the same as the area used
>> for amenity=restaurant. maybe it should be the area for the dining room.
>> the wiki advice to put both tag to the same polygon look like wrong.
>>
>>
>> Le 18. 04. 18 à 11:56, Marc Gemis a écrit :
>> > o, I forgot, what about a restaurant that occupies multiple floors ?
>> >
>> >
>> >
>> > On Wed, Apr 18, 2018 at 11:55 AM, Marc Gemis 
>> > wrote:
>> >> The idea of using indoor mapping is good, and it's probably the future
>> >> to solve all the problems you mention. (we had a similar discussion
>> >> last Friday on the Riot channel)
>> >>
>> >> Some remarks:
>> >>
>> >> - does it make sense for a "room" to have an house number and a street
>> >> ? I would expect those on the building, and floor or level or so on
>> >> the room.
>> >> - I'm not familiar enough with the simple  indoor tagging, but I would
>> >> expect that a restaurant exists of multiple rooms (dining, toilets,
>> >> kitchen) not just one.
>> >> - On the Riot channel the entrance to the restaurant was also seen as
>> >> important.
>> >>
>> >> m
>> >>
>> >> On Wed, Apr 18, 2018 at 10:06 AM, Ubipo . 
>> >> wrote:
>> >>> Everyone,
>> >>>
>> >>> A long standing question for osm mapping in cities is wether to tag
>> >>> amenities in multi-purpose buildings as:
>> >>> - a separate node inside the building's way
>> >>> - the building itself, using both building=house and amenity=* (only
>> >>> valid
>> >>> with single-amenity buildings)
>> >>> The node approach has consistency issues like these buildings:
>> >>> https://www.openstreetmap.org/node/656793551 .
>> >>>
>> >>> The area approach is more consistent but doesn't really allow
>> >>> multi-purpose
>> >>> buildings.
>> >>> A third, lesser used method is to use part of the simple indoor
>> >>> tagging
>> >>> schema. I've used a simplified version of this for this restaurant:
>> >>> https://www.openstreetmap.org/way/580985564 .
>> >>> This approach uses two overlapping ways, one for the general building
>> >>> (tagged building=house) and one for the restaurant on the ground floor
>> >>> (tagged room=restaurant and of course amenity=restaurant).
>> >>>
>> >>> Drawbacks of this are for one that the two ways fully overlap. This
>> >>> triggers
>> >>> the JOSM validator and probably some QC tools. Secondly renderers
>> >>> might have
>> >>> trouble placing the icons and house numbers of multiple areas like
>> >>> this.
>> >>> Luckily both these problems could be fixed. The positives are of
>> >>> course:
>> >>> consistency and the possibility for multiple amenities (using the
>> >>> level=*
>> >>> key).
>> >>>
>> >>> What do you all think of this approach?
>> >>>
>> >>> Kind regards,
>> >>> Pieter (Ubipo)
>> >>>
>> >>> ___
>> >>> 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
>> 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
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-de] Attribute für Rettungswachen, Bergwachten, Hilfsorganisationen

[Tom Pfeifer]

Das Taggen der Hilfsorganisationen ist recht chaotisch, daher ist ja seit langem der 
"Emergency-cleanup" im Wiki annonciert, wird aber nur halbherzig betrieben.


Für die Bergrettung würde sich "emergency=mountain_rescue" anbieten, bisher 2 
Verwendungen.

Für den Zivilschutz hatte ein Australier mal "emergency=ses_station" etabliert, was wegen des 
nationalen Acronyms SES ungeeignet ist [1].


Bei den Diskussionen dort, ob emergency=disaster_response geeignet wäre, stieß ich auf die 
derzeitige Verwendung beim deutschen Technischen Hilfswerk (THW) nach dem Schema 
amenity=emergency_service + emergency_service=technical, was einem Proposal von 2008 [2] folgt.


[1] https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dses_station
[2] https://wiki.openstreetmap.org/wiki/Proposed_features/Emergency_service

Tom

On 15.04.2018 14:04, Lena Essig wrote:

Hallo zusammen,

mir ist aufgefallen, dass bei der Suche nach "emergency"="ambulance_station"
nicht nur Rettungswachen angezeigt werden, sondern auch Bergwachten oder
auch Ortsvereine.
Nur sehr wenige der Bergwachten sind mit "amenity"="mountain_rescue"
getaggt.
Da Bergwachten nur besondere Einsatzarten übernehmen, sollten sie von
normalen Rettungswachen unterschieden werden. Ebenso Ortsvereine der
einzelnen Hilfsorganisationen, da sie nichts mit dem Rettungsdienst zu tun
haben.
Wie ist denn die allgemeine Regelung für Orstvereine oder
Katastrophenschutzzentren?



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

Re: [Talk-GB] Addressing of flats: review best practice

[Derick Rethans]

On Tue, 17 Apr 2018, Andrew Hain wrote:

> I have been mapping a complex of flats that consists of a series of 
> blocks each with its own entrance, tagging each section with 
> addr:housename and addr:flats 
> [https://www.openstreetmap.org/way/580234651]. The standard layer 
> repeats the name of the whole block for each section, which I find a 
> bit clunky (Humanitarian doesn’t label anything at all). Before I 
> discuss this with the map renderers, am I doing the best thing for 
> tagging?

Yes, I think so. I have a similar situation here:
https://www.openstreetmap.org/#map=19/51.53422/-0.19844

Although I mapped the whole building there with its name, and then each 
entrance separately as I don't know where the sections are exactly.

I wrote a style change some time ago too: 
https://derickrethans.nl/flats.html — but nothing on that front has 
improved yet :-/

I wish it would render similarly to 
https://www.openstreetmap.org/way/282084602#map=19/51.52662/-0.18901=D 
perhaps :-/

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk-fr] Atelier OSM - WebCome Day - samedi 28 avril - 14h-15h45

[Rene Chalon]

Bonjour à tou.te.s,

La conférence scientifique mondiale du web (The Web Conference, 
https://www2018.thewebconf.org) revient pour la 2ème fois à Lyon du 23 
au 27 avril prochain. En accompagnement, les acteurs locaux organisent 
un "OFF" sous le nom de WebCome Lyon (https://webcomelyon.fr/) qui 
propose des événements grands publics tout au long de l'année 2018.


En clôture de la conférence, le samedi 28 avril prochain, de 10h à 19h, 
se tient une journée faisant le lien IN/OFF, le WebCome Day, dans les 
locaux de l'Université de Lyon, 92 rue Pasteur, dans le 7ème 
arrondissement : https://webcomelyon.fr/webcome-day/.


OpenStreetMap y anime un atelier de 14h à 15h45 qui propose de faire 
découvrir l'utilisation d'OpenStreetMap, le "Wikipedia de la 
cartographie", et de comprendre comment contribuer à son enrichissement.


En fonction de l’intérêt des participant.e.s, différents thèmes peuvent 
être abordés, éventuellement en sous-groupes séparés :
- Utiliser OpenStreetMap sur son téléphone mobile pour la navigation en 
voiture, à pied, en VTT,
- Créer son compte personnel, faire des corrections, ajouter des 
informations géographiques en utilisant différentes sources 
d'informations libres

- S’initier à l’usage des outils informatiques associés.
- Réaliser des cartes personnalisées sur un fond de carte OpenStreetMap
- Extraire des données et les intégrer dans un SIG

Pour une participation active, il est vivement recommandé d'apporter son 
ordinateur portable...


Inscription : 
https://docs.google.com/forms/d/e/1FAIpQLSeZBHZJ-IDK811bTOr2qshiWoWGReJKw-z3fUDZJ65q85WQlQ/viewform


En espérant vous voir nombreux.ses,
René Chalon (aka renecha).

PS: Remerciements aux co-animateurs de l'atelier : Alain (Al-Hun), 
Camille, Françoise (Fphilly) et Sylvain (Ecologeek).




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

Re: [OSM-talk-be] Nodes or areas to tag amenities

[Ubipo .]

Regarding the housenumbers: street and number is as said probably not
needed and better reserved for the actual building, although a specialised
addr:addition=a could be useful for the rooms.
Regarding room=restaurant, I think that tag is perfectly fine. It just
indicates the restaurant in it's entirety, with dining room, kitchen etc.

On Wed, Apr 18, 2018, 12:10 marc marc  wrote:

> for the addr : it look like strange that the room is in a building that
> doesn't have the same addr:housenumber as the building.
>
> for multiple floors poi, you can draw all room with level=* tag
> or as a first step only use indoor=yes for the whole area
>
> room=restaurant look like also strange for me.
> a restaurant is several room=* item : kitchen, dining room, toilets,
> cloakroom
> so what's a room=restaurant ? it can not be the same as the area used
> for amenity=restaurant. maybe it should be the area for the dining room.
> the wiki advice to put both tag to the same polygon look like wrong.
>
>
> Le 18. 04. 18 à 11:56, Marc Gemis a écrit :
> > o, I forgot, what about a restaurant that occupies multiple floors ?
> >
> >
> >
> > On Wed, Apr 18, 2018 at 11:55 AM, Marc Gemis 
> wrote:
> >> The idea of using indoor mapping is good, and it's probably the future
> >> to solve all the problems you mention. (we had a similar discussion
> >> last Friday on the Riot channel)
> >>
> >> Some remarks:
> >>
> >> - does it make sense for a "room" to have an house number and a street
> >> ? I would expect those on the building, and floor or level or so on
> >> the room.
> >> - I'm not familiar enough with the simple  indoor tagging, but I would
> >> expect that a restaurant exists of multiple rooms (dining, toilets,
> >> kitchen) not just one.
> >> - On the Riot channel the entrance to the restaurant was also seen as
> important.
> >>
> >> m
> >>
> >> On Wed, Apr 18, 2018 at 10:06 AM, Ubipo . 
> wrote:
> >>> Everyone,
> >>>
> >>> A long standing question for osm mapping in cities is wether to tag
> >>> amenities in multi-purpose buildings as:
> >>> - a separate node inside the building's way
> >>> - the building itself, using both building=house and amenity=* (only
> valid
> >>> with single-amenity buildings)
> >>> The node approach has consistency issues like these buildings:
> >>> https://www.openstreetmap.org/node/656793551 .
> >>>
> >>> The area approach is more consistent but doesn't really allow
> multi-purpose
> >>> buildings.
> >>> A third, lesser used method is to use part of the simple indoor tagging
> >>> schema. I've used a simplified version of this for this restaurant:
> >>> https://www.openstreetmap.org/way/580985564 .
> >>> This approach uses two overlapping ways, one for the general building
> >>> (tagged building=house) and one for the restaurant on the ground floor
> >>> (tagged room=restaurant and of course amenity=restaurant).
> >>>
> >>> Drawbacks of this are for one that the two ways fully overlap. This
> triggers
> >>> the JOSM validator and probably some QC tools. Secondly renderers
> might have
> >>> trouble placing the icons and house numbers of multiple areas like
> this.
> >>> Luckily both these problems could be fixed. The positives are of
> course:
> >>> consistency and the possibility for multiple amenities (using the
> level=*
> >>> key).
> >>>
> >>> What do you all think of this approach?
> >>>
> >>> Kind regards,
> >>> Pieter (Ubipo)
> >>>
> >>> ___
> >>> 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
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-in] Mapping Himalayan Glaciers

[Chetan H A]

Jinal and Arun, Thanks for putting it together as a task. There is a
interesting blog written by Christoph Hormann back in 2013 on the state of
glacier mapping in OSM: http://www.imagico.de/map/osm_glaciers_en.php

This will give some sense of importance of glaciers.



On Wed, Apr 18, 2018 at 3:30 PM, Arun Ganesh 
wrote:

> For earth day, we have a special mapping task created to map Himalayan
> Glaciers in India. All the details and instructions are available here:
> https://osm.earth/project/23
>
> Thanks to Jinal for taking the lead to put this together! Feel free to
> spread the word and join in.
>
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-in
>
>
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [OSM-talk-be] Nodes or areas to tag amenities

[marc marc]

for the addr : it look like strange that the room is in a building that 
doesn't have the same addr:housenumber as the building.

for multiple floors poi, you can draw all room with level=* tag
or as a first step only use indoor=yes for the whole area

room=restaurant look like also strange for me.
a restaurant is several room=* item : kitchen, dining room, toilets, 
cloakroom
so what's a room=restaurant ? it can not be the same as the area used 
for amenity=restaurant. maybe it should be the area for the dining room.
the wiki advice to put both tag to the same polygon look like wrong.


Le 18. 04. 18 à 11:56, Marc Gemis a écrit :
> o, I forgot, what about a restaurant that occupies multiple floors ?
> 
> 
> 
> On Wed, Apr 18, 2018 at 11:55 AM, Marc Gemis  wrote:
>> The idea of using indoor mapping is good, and it's probably the future
>> to solve all the problems you mention. (we had a similar discussion
>> last Friday on the Riot channel)
>>
>> Some remarks:
>>
>> - does it make sense for a "room" to have an house number and a street
>> ? I would expect those on the building, and floor or level or so on
>> the room.
>> - I'm not familiar enough with the simple  indoor tagging, but I would
>> expect that a restaurant exists of multiple rooms (dining, toilets,
>> kitchen) not just one.
>> - On the Riot channel the entrance to the restaurant was also seen as 
>> important.
>>
>> m
>>
>> On Wed, Apr 18, 2018 at 10:06 AM, Ubipo .  wrote:
>>> Everyone,
>>>
>>> A long standing question for osm mapping in cities is wether to tag
>>> amenities in multi-purpose buildings as:
>>> - a separate node inside the building's way
>>> - the building itself, using both building=house and amenity=* (only valid
>>> with single-amenity buildings)
>>> The node approach has consistency issues like these buildings:
>>> https://www.openstreetmap.org/node/656793551 .
>>>
>>> The area approach is more consistent but doesn't really allow multi-purpose
>>> buildings.
>>> A third, lesser used method is to use part of the simple indoor tagging
>>> schema. I've used a simplified version of this for this restaurant:
>>> https://www.openstreetmap.org/way/580985564 .
>>> This approach uses two overlapping ways, one for the general building
>>> (tagged building=house) and one for the restaurant on the ground floor
>>> (tagged room=restaurant and of course amenity=restaurant).
>>>
>>> Drawbacks of this are for one that the two ways fully overlap. This triggers
>>> the JOSM validator and probably some QC tools. Secondly renderers might have
>>> trouble placing the icons and house numbers of multiple areas like this.
>>> Luckily both these problems could be fixed. The positives are of course:
>>> consistency and the possibility for multiple amenities (using the level=*
>>> key).
>>>
>>> What do you all think of this approach?
>>>
>>> Kind regards,
>>> Pieter (Ubipo)
>>>
>>> ___
>>> 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
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-dk] autoAWS første udkast

[Ole Laursen]

18. april 2018 kl. 10.58 skrev Jonathan Hougaard :
> Jeg vil eksperimentere med at indhente vejnavne fra OISfixes - men jeg kan
> se dataet er formatteret så det er nemt at tilgå, så det burde være rimelig
> simpelt at få til at fungere :)
>
> Vil du foretrække, at jeg periodevis henter en komplet kopi af databasen ned
> og så kalder den, eller at jeg kalder din database for et enkelt vejstykke
> af gangen? Umiddelbart foretrækker jeg mulighed #2 da jeg helst ikke vil ud
> i noget duplikering af data hvor det ikke er nødvendigt - medmindre du er
> træt af at jeg laver nogle tusinde små anmodninger til databasen (alle vil
> være med en specifik kommunekode og vejkode).

Hvis du laver et kald per punkt du skal sammenligne, kommer du måske
til at dø i latency, men det er ikke noget problem at du f.eks. hiver
dataene ud hver gang du starter en kørsel på en række punkter. Jeg
tror alle rettelserne pt. fylder noget i stil med 50 kB som JSON... :)


Ole

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

[Talk-in] Mapping Himalayan Glaciers

[Arun Ganesh]

For earth day, we have a special mapping task created to map Himalayan
Glaciers in India. All the details and instructions are available here:
https://osm.earth/project/23

Thanks to Jinal for taking the lead to put this together! Feel free to
spread the word and join in.
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [OSM-talk-be] Nodes or areas to tag amenities

[Marc Gemis]

o, I forgot, what about a restaurant that occupies multiple floors ?



On Wed, Apr 18, 2018 at 11:55 AM, Marc Gemis  wrote:
> The idea of using indoor mapping is good, and it's probably the future
> to solve all the problems you mention. (we had a similar discussion
> last Friday on the Riot channel)
>
> Some remarks:
>
> - does it make sense for a "room" to have an house number and a street
> ? I would expect those on the building, and floor or level or so on
> the room.
> - I'm not familiar enough with the simple  indoor tagging, but I would
> expect that a restaurant exists of multiple rooms (dining, toilets,
> kitchen) not just one.
> - On the Riot channel the entrance to the restaurant was also seen as 
> important.
>
> m
>
> On Wed, Apr 18, 2018 at 10:06 AM, Ubipo .  wrote:
>> Everyone,
>>
>> A long standing question for osm mapping in cities is wether to tag
>> amenities in multi-purpose buildings as:
>> - a separate node inside the building's way
>> - the building itself, using both building=house and amenity=* (only valid
>> with single-amenity buildings)
>> The node approach has consistency issues like these buildings:
>> https://www.openstreetmap.org/node/656793551 .
>>
>> The area approach is more consistent but doesn't really allow multi-purpose
>> buildings.
>> A third, lesser used method is to use part of the simple indoor tagging
>> schema. I've used a simplified version of this for this restaurant:
>> https://www.openstreetmap.org/way/580985564 .
>> This approach uses two overlapping ways, one for the general building
>> (tagged building=house) and one for the restaurant on the ground floor
>> (tagged room=restaurant and of course amenity=restaurant).
>>
>> Drawbacks of this are for one that the two ways fully overlap. This triggers
>> the JOSM validator and probably some QC tools. Secondly renderers might have
>> trouble placing the icons and house numbers of multiple areas like this.
>> Luckily both these problems could be fixed. The positives are of course:
>> consistency and the possibility for multiple amenities (using the level=*
>> key).
>>
>> What do you all think of this approach?
>>
>> Kind regards,
>> Pieter (Ubipo)
>>
>> ___
>> 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

Re: [OSM-talk-be] Nodes or areas to tag amenities

[Marc Gemis]

The idea of using indoor mapping is good, and it's probably the future
to solve all the problems you mention. (we had a similar discussion
last Friday on the Riot channel)

Some remarks:

- does it make sense for a "room" to have an house number and a street
? I would expect those on the building, and floor or level or so on
the room.
- I'm not familiar enough with the simple  indoor tagging, but I would
expect that a restaurant exists of multiple rooms (dining, toilets,
kitchen) not just one.
- On the Riot channel the entrance to the restaurant was also seen as important.

m

On Wed, Apr 18, 2018 at 10:06 AM, Ubipo .  wrote:
> Everyone,
>
> A long standing question for osm mapping in cities is wether to tag
> amenities in multi-purpose buildings as:
> - a separate node inside the building's way
> - the building itself, using both building=house and amenity=* (only valid
> with single-amenity buildings)
> The node approach has consistency issues like these buildings:
> https://www.openstreetmap.org/node/656793551 .
>
> The area approach is more consistent but doesn't really allow multi-purpose
> buildings.
> A third, lesser used method is to use part of the simple indoor tagging
> schema. I've used a simplified version of this for this restaurant:
> https://www.openstreetmap.org/way/580985564 .
> This approach uses two overlapping ways, one for the general building
> (tagged building=house) and one for the restaurant on the ground floor
> (tagged room=restaurant and of course amenity=restaurant).
>
> Drawbacks of this are for one that the two ways fully overlap. This triggers
> the JOSM validator and probably some QC tools. Secondly renderers might have
> trouble placing the icons and house numbers of multiple areas like this.
> Luckily both these problems could be fixed. The positives are of course:
> consistency and the possibility for multiple amenities (using the level=*
> key).
>
> What do you all think of this approach?
>
> Kind regards,
> Pieter (Ubipo)
>
> ___
> 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

Re: [talk-au] Canberra Contact

[Marc Gemis]

I guess this is the same person that started the thread
https://forum.openstreetmap.org/viewtopic.php?id=62047 on the forum.
Andrew was so kind to give some feedback there. He invited the person
to join this mailing list.

regards

m

On Wed, Apr 18, 2018 at 11:24 AM, Alex Sims  wrote:
> Hi,
>
> I’ve been approached by email from an ACT Government public servant wanting a 
> contact to discuss sharing (Canberra) data with OSM. Is there a Canberra/ACT 
> based mapper who would like to take this on? (I’m in Adelaide)
>
> Alex
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

[talk-au] Canberra Contact

[Alex Sims]

Hi,

I’ve been approached by email from an ACT Government public servant wanting a 
contact to discuss sharing (Canberra) data with OSM. Is there a Canberra/ACT 
based mapper who would like to take this on? (I’m in Adelaide)

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

Re: [talk-latam] [Talk-bo] supervisar ediciones masivas en cochabamba

[Juan Jose Iglesias]

Saludos

Si bien los chicos que estan hacienda las ediciones masivas en "edificaciones" 
siguen su trabajo en Cochabamba; ahora empezamos a bombardearlos (en el buen 
sentido) con "correcciones" tanto las que Marco Antonio envia como otras en 
Ingles, debido a la abundante cantidad de nodos repetidos y auto intersección 
de vias que producen; Obviamente ninguno de ellos tienen idea de estos errores; 
y mas si le llegan notas en un idioma que posiblemente no manejen y con enlaces 
a geofabrick.de y otras herramientas de QA.

En lo personal NO creo q sea buena idea en este momento tratar de "hacerlos 
corregir" sus propias ediciones sino mas bien sugeriría preparar una lista 
minina de como crear y editar una edificación (para niños chiquitos) y 
enviársela a todos los parbulos .

La verdad que a todos ellos les he enviado un mensaje de bienvenida y con 
enlaces a las reglas de edición para Bolivia, además de ciertas reglas de juego
https://wiki.openstreetmap.org/wiki/ES:Bolivia:Map_Features
https://wiki.openstreetmap.org/wiki/ES:C%C3%B3mo_mapear..._(en_Bolivia)

De las docenas de mensajes que he enviado apenas 1 sola chica me contesto; asi 
que asumo que la mayoría no han leído esos mensajes y posiblemente tampoco lean 
las "Discusiones" de los Changesets. Sigo convencido que la mejor solución debe 
ser reunirse con el "Profesor" que puso la tarea y ver si Marco Antonio puede 
organizar 1 sesion de entrenamiento con un grupo bueno de ellos y que sirvan de 
multiplicadores; sino esto seguirá por el tiempo que les lleve completar la 
tarea que les pusieron...

Entiendo que Marco Antonio tiene reservada una edición masiva de elementos como 
los nombres VIVIENDA, CASA, TIENDA, etc, etc; pero obviamente no todo se 
restringe a eso pues han cambiado vías, borrado otras o zonas existentes, y 
cosas por el estilo; esta bien cuando eso lo hacen 2 o 3 personas; pero muy 
complicado con docenas de editores cumpliendo un trabajo escolar/universitario.

Se escuchan sugerencias de como lidiar con este "muy particular" problema

Saludos

JJ




-Original Message-
From: Marco Antonio [mailto:marcoantoniofr...@gmail.com] 
Sent: Monday, April 16, 2018 1:46 AM
To: OSM Bolivia 
Subject: [Talk-bo] supervisar ediciones masivas en cochabamba

hola,

hace algunas semanas vienen 'editando y añadiendo huellas de edificios y a 
veces tipos de edificio' estudiantes universitarios en cochabamba.

Son como 120 usuarios, entre mujeres y hombres por igual no se les explicó 
algunas directrices básicas de 'lectura y creación de mapas' ni como editar 
elementos categorizados, no es diferente a la forma en como cada una de 
nosotros llegamos a editar al principio aquí al mapa

hace unos 7 días atrás estoy supervisando usuario por usuario las ediciones 
hechas y que tienen problemas:

* eliminaron o movieron al azar negocios sin justificación
* hicieron clics involuntarios y arruinaron trazos de calles
* huellas de edificios inventados porque se aburrieron de dibujar la realidad y 
solo completaron por la nota
* no escogieron una categoría al área creada
* huellas de edificios duplicados por error de editor ID con conexiones malas 
de internet
* poner nombres ficticios o que redundan la característica de una categoría 
(áreas de edificios con nombre edificio)

Estoy solucionando todos los puntos anteriores menos el ultimo porque el ultimo 
lo haré masivo al final con JOSM y overpass, el resto es mas urgente ya que 
baja la calidad del mapa de cochabamba ciudad que esbueno en general

Estoy revisando desde las primeras edificiones (hace 14 días) usuario por 
usuario y mandando mensajes en sus changesets y un mensaje final en su ultimo 
changeset con sus errores y un mensaje para seguir mapeando o preguntando, ya 
solucione de 15 o 20 usuarios

Faltan varios que iré solucionando esta semana que ya no estoy de viaje, unos 
mapeadores alemanes están ayudando a solucionar errores ciclicos

Estoy usando

achavi, para ver cambios visualmente y rapido 
https://wiki.openstreetmap.org/wiki/Achavi

last osm contributor, para ver quienes se dieron de alta
http://www.resultmaps.neis-one.org/newestosm?c=Bolivia#6/-19.021/-65.973

whodidit
https://simon04.dev.openstreetmap.org/whodidit/

feed RSS de changesets inverso
osm-qa-feeds

PD: estare mandando un correo mas entre semana antes de empezar con la solución 
masiva de coregir nombres de edificios mal hechos o inventados

abrazos,

Marco Antonio

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


---
This email has been checked for viruses by AVG.
http://www.avg.com


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

Re: [Talk-dk] autoAWS første udkast

[Jonathan Hougaard]

Hej Ole


Jeg skal beklage, at jeg ikke lige fik kigget ordentligt på OIS fix 
siden da du sendte den sidst.


Jeg vil eksperimentere med at indhente vejnavne fra OISfixes - men jeg 
kan se dataet er formatteret så det er nemt at tilgå, så det burde være 
rimelig simpelt at få til at fungere :)


Vil du foretrække, at jeg periodevis henter en komplet kopi af databasen 
ned og så kalder den, eller at jeg kalder din database for et enkelt 
vejstykke af gangen? Umiddelbart foretrækker jeg mulighed #2 da jeg 
helst ikke vil ud i noget duplikering af data hvor det ikke er 
nødvendigt - medmindre du er træt af at jeg laver nogle tusinde små 
anmodninger til databasen (alle vil være med en specifik kommunekode og 
vejkode).



On 18/04/2018 09:16, Ole Laursen wrote:

Hej Jonathan

18. april 2018 kl. 08.13 skrev Jonathan Hougaard :

Jeg er med på, at data fra DAR ikke er 100% korrekt. Det ændrer ikke ved, at
det er den tilgang,  jeg er nødt til at have. Hvis jeg derimod skal antage,
at data fra DAR som udgangspunkt er forkert, kan vi jo lige så godt droppe
importen.

Beklager, jeg skulle måske have uddybet før - jeg havde indtryk af at
du havde læst tilbage på postlisten, det lød sådan på din første
email.

Den oprindelige robot havde nøjagtig den tilgang du skriver nu.

Det resulterede så i at flere tusinde adresseknuder havde absurde
vejnavne, som Niels lige har illustreret. En tid ignorerede vi
problemet og opkaldte bare vejene korrekt. Men så fik vi det problem
at inkonsistensværktøjerne jo sammenligner vejnavne med nærliggende
adresseknuder og melder fejl hvis der ikke er overensstemmelse.

Det gik vi så i fællesskab og spekulerede over et stykke tid indtil
jeg så lavede

https://oisfixes.iola.dk

Kan jeg overtale dig til at prøve at bruge bare 5 minutter inde på den side?

Løsningen var, som du kan se, at lave en database over fejl i DAR. Det
havde to formål: robotten kunne så rette vejnavnene til når den
importerede, og kommunerne kunne gå ind og se fejl i deres data.

Logikken er ret enkel: der er en JSON-grænseflade som importeren
starter med at hente data fra, putter i et associativt array og slår
op om der er en rettelse hver gang den processerer en knude.

Nu fandt jeg lige den email hvor Peter Brodersen skrev at han havde
fået importeren til at tage rettelser ind fra oisfixes:

https://lists.openstreetmap.org/pipermail/talk-dk/2011-September/001818.html

Så det er ikke sådan at du behøver at bruge lang tid på at genopfinde
fejlhåndtering - vi har allerede været det igennem. Det er muligt
arbejdsgangen kan være smartere - hvis du har et forslag, så vil jeg
gerne kigge på at omkode eller evt. afvikle oisfixes.


Du har helt ret i, at der sikkert både er og vil komme nye fejl i
DAR-dataen. 100% korrekt data findes i denne sammenhæng ikke. Jeg mener dog
stadig, at den 99% korrekte data vi kan hente fra DAR er langt bedre end
manuel tilretning af samtlige adresser i Danmark, hvilket er helt
urealistisk.

Jeg tror du lige skal et skridt tilbage og se at der er en mulighed mere:

auto-import + individuelle rettelser fra OSM-miljøet > auto-import >
manuel import


Ole

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



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

[OSM-talk-be] Nodes or areas to tag amenities

[Ubipo .]

Everyone,

A long standing question for osm mapping in cities is wether to tag
amenities in multi-purpose buildings as:
- a separate node inside the building's way
- the building itself, using both building=house and amenity=* (only valid
with single-amenity buildings)
The node approach has consistency issues like these buildings:
https://www.openstreetmap.org/node/656793551 .

The area approach is more consistent but doesn't really allow multi-purpose
buildings.
A third, lesser used method is to use part of the simple indoor tagging
schema. I've used a simplified version of this for this restaurant:
https://www.openstreetmap.org/way/580985564 .
This approach uses two overlapping ways, one for the general building
(tagged building=house) and one for the restaurant on the ground floor
(tagged room=restaurant and of course amenity=restaurant).

Drawbacks of this are for one that the two ways fully overlap. This
triggers the JOSM validator and probably some QC tools. Secondly renderers
might have trouble placing the icons and house numbers of multiple areas
like this.
Luckily both these problems could be fixed. The positives are of course:
consistency and the possibility for multiple amenities (using the level=*
key).

What do you all think of this approach?

Kind regards,
Pieter (Ubipo)
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Liens vers communauté FR sur iD...

[PanierAvide]

Bonjour,

Pour éviter les doublons d'infos, on ne peut pas se baser sur la carte 
des groupes locaux ?

http://umap.openstreetmap.fr/fr/map/groupes-locaux-openstreetmap_152488#6/46.392/1.714

Cordialement,

Adrien.

Le 18/04/2018 à 09:26, Christian Quest a écrit :
La dernière version d'iD (ou la prochaine) peut afficher des liens 
vers les canaux de communication de la communauté OSM après la 
sauvegarde de ses contributions.


Ces liens dépendent de la zone où l'on a contribué et sont donc bien 
adapté pour pousser les nouveaux contributeurs à se mettre en contact 
avec le reste de la communauté locale.


J'ai ajouté les liens vers les canaux d'OSM France sur le dépôt github :

https://github.com/osmlab/osm-community-index/pull/83

Il est possible de descendre à un niveau encore plus local...

Il faut quelques fichiers json:
- un geojson qui définit la zone géographique
- un json pour définir chaque lien (mailinglist, forum, twitter, etc)

Les libellés sont à mettre en anglais... pour la traduction, je pense 
que c'est dans le transiflex d'iD (pas super pratique de séparer, mais 
bon).


--
Christian Quest - OpenStreetMap France


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



--
PanierAvide
Géomaticien & développeur

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

[OSM-talk-fr] Liens vers communauté FR sur iD...

[Christian Quest]

La dernière version d'iD (ou la prochaine) peut afficher des liens vers les
canaux de communication de la communauté OSM après la sauvegarde de ses
contributions.

Ces liens dépendent de la zone où l'on a contribué et sont donc bien adapté
pour pousser les nouveaux contributeurs à se mettre en contact avec le
reste de la communauté locale.

J'ai ajouté les liens vers les canaux d'OSM France sur le dépôt github :

https://github.com/osmlab/osm-community-index/pull/83

Il est possible de descendre à un niveau encore plus local...

Il faut quelques fichiers json:
- un geojson qui définit la zone géographique
- un json pour définir chaque lien (mailinglist, forum, twitter, etc)

Les libellés sont à mettre en anglais... pour la traduction, je pense que
c'est dans le transiflex d'iD (pas super pratique de séparer, mais bon).

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

Re: [Talk-it] [ItalyFuelStations] revisione pre-import

[Cascafico Giovanni]

Il giorno 18 aprile 2018 00:00, Francesco Frassinelli 
ha scritto:

>
> Ho qualche dubbio su quando e come usare il tag fixme in questi casi:
> - OSM segna come benzinaio l'edificio e non la tettoia con le pompe (come
> pare fare il dataset MISE) -> giusto o fixme (e se sì, cosa scriverci?)
>

Ho visto parecchi punti di MISE e mi semba la maggior parte siano prossimi
alla tettoia. IMHO non è un grosso problema se degli OSMer abbiano mappato
la casetta dove c'è la cassa: lascierei i fixme per casi più eclatanti.


> - Posizione semplicemente sbagliata -> fixme con quale commmento?
>

Finora ho messo "adjust location" quando è visibile la posizione corretta
nelle img aeree, mentre "check location" se non si vede o ci sono dubbi
interpretativi.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-dk] autoAWS første udkast

[Jonathan Hougaard]

Hej Niels


Jeg er med på, at data fra DAR ikke er 100% korrekt. Det ændrer ikke 
ved, at det er den tilgang,  jeg er nødt til at have. Hvis jeg derimod 
skal antage, at data fra DAR som udgangspunkt er forkert, kan vi jo lige 
så godt droppe importen.



Scriptet kan oversætte de forkortelser som vi fortæller det. Skal Dr. så 
være Doktor eller Dronning? Tja, hvis jeg var turist i en ny by ville 
jeg heller ikke selv kunne kende forskel. Så i den forstand er problemet 
jo ikke unikt. Dog kunne et udgangspunkt for oversættelse af 
forkortelser være Dansk Sprognævns vejledning i retskrivning af vejnavne 
(http://danmarksadresser.dk/file/383079/ds-vejledning-retskrivning.pdf). 
Har forkortes Doktor i øvrigt Dr. mens Dronning forkortes Dronn.



Du har helt ret i, at der sikkert både er og vil komme nye fejl i 
DAR-dataen. 100% korrekt data findes i denne sammenhæng ikke. Jeg mener 
dog stadig, at den 99% korrekte data vi kan hente fra DAR er langt bedre 
end manuel tilretning af samtlige adresser i Danmark, hvilket er helt 
urealistisk.



On 17/04/2018 14:18, Niels Elgaard Larsen wrote:

On Tue, 17 Apr 2018 11:13:12 +0200
Jonathan Hougaard  wrote:



Mht. 4 - som nævnt tidligere, er min tilgang generelt (nødt til at
være), at data fra DAR er korrekt.

Men det er data fra DAR altså ikke altid. Datakvaliteten er høj, men
det er ikke perfekt.


Jeg har ikke deltaget i den nævnte
diskussion, og kender derfor ikke argumenterne. Teknisk kan jeg godt,
hvis der er konsensus om det, rette forkortede vejnavne til deres
fulde navn før de importeres. Dette kræver, at der er en eller anden,
der laver en komplet liste med forkortelser og deres udvidede form
(Dr. = Doktor, Nr. = Nørre osv.)

Men er dit system så smart nok til at vide at "Dr. Dorothea" er Dronning
Dorothea og ikke Doktor Dorothea?


Umiddelbart har jeg lidt svært ved at forstå, hvorfor vi ønsker at
ændre de tilsyneladende officielle vejnavne fra DAR,

Fordi de ikke er korrekte. Og de er heller ikke officielle. Det er bare
en database. Mange af fejlene i DAR skyldes at vejnavnene oprindeligt
er indtastet i et system, hvor der kun var plads til 20 tegn for
vejnavne. Det gør ikke Borgm.Jespersensvej til et officielt vejnavn, så
kommunen kører ud og skifter alle skiltene.

Det ser ud til at de fleste fixes på OIS-fixes nu er rettet i
DAR, (fx Tengslemrk Strandvej => Tengslemark Strandvej).

Men der var jo så et stykke tid hvor navnene var korrekte i OSM, men
endnu ikke rettet i DAR/AWS. Og måske har de rettet det fordi de så
rettelsen i OSM. Under alle omstændigheder kommer der sikkert nye veje
med fejl i DAR, som de vil være lang til om at rette.



men som sagt
kender jeg ikke argumenterne.



Mht. position, som tidligere diskuteret et sted i forrige tråd, bør
fejl rettes direkte hos DAR.

Igen, der kan gå lang tid inden vi får rettet fejl i DAR.
Og hvis vi ved at data i OSM er forkerte, skal der være en måde at
rette dem i OSM indtil de bliver rettet i DAR.


Hvis der er helt exceptionelle tilfælde
hvor en adresseknude i OSM ikke skal placeres på den officielle
placering (jeg kan ikke umiddelbart komme på nogen!),

https://overpass-turbo.eu/s/xYk
Mange af dem er rettet i DAR, så vi burde gå dem igennem og rydde op.

Men der er stadig mærkelige ting i DAR.

Fx at der både er Gl. Strandvej 237 i Humlebæk og Gammel Strandvej 237 i
Espergærde.


  kan vi
eventuelt anvende et specielt tag, så knuden bliver ignoreret
(autoaws=ignore eller hvad ved jeg). Så vidt jeg forstår, har AWSbot
haft en tilsvarende funktion.

Vi kan vel fortsætte med ois:fixme
  

On 17/04/2018 10:26, Jakob Barfod wrote:

I må meget gerne kigge beskrivelsen igennem og komme med forslag og
kommentarer til dette.

1. Rigtig godt arbejde!

2. Foretrækker du, at diskussion foregåer her på talk-dk eller på
diskussionssiden på wiki'en? 2.a. Hvis her på talk-dk, så opretter
jeg lige en henvisning på wiki'en.

3. Henvisninger til AWSbot på diverse wiki-sider bør opdateres, så
AutoAWS nævnes i stedet. Ikke ment sådan, at _du_ skal gøre det,
men hermed efterlyses steder, hvor vi bør opdatere diverse tekster.
Fx... 3.a https://wiki.openstreetmap.org/wiki/Addresses#Denmark 3.b
https://www.openstreetmap.org/user/AWSbot 3.c
https://wiki.openstreetmap.org/wiki/Import/Catalogue/KMS 3.d Flere?

4. Konfliktende opdateringer? Hvem har ret, DAR eller OSM?
Jf. den gamle "Dr. Tværgade<>Doktor Tværgade"-diskussion, så lægger
jeg mærke til, at stavningen fra DAR bruges, hvis der er forskel:

 "Any one of the following conditions will trigger an update:
 [...]
 The position (lat and lon) of the node is not equal to the AWS
address position addr:street=* is not equal to the AWS street name "

Er det hensigtsmæssigt? Hvad nu hvis en OSM-bruger har tilrettet
forkerte data (fx position eller stavning af vejnavn)? Det kan jeg
simpelthen ikke gennemskue.


___
Talk-dk mailing list
Talk-dk@openstreetmap.org