[talk-cz] WeeklyOSM CZ 455

[Tom Ka]

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

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

* Skály pro lezce.
* Zbyho občasník.
* Otevření dat v Plzni.
* Mapování dopravních značek.
* Strojové učení a solární panely.
* Menší pokrytí budov v Rakousku.
* Nové hodnoty landcover.
* Oblečení volitelné?
* Transparentní platy HOT.
* Poděkování Lékařů bez hranic.
* Narovnané řeky v Evropě.
* Supové a státní hranice.

Pěkné počtení ...

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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

On 4/25/2019 8:39 PM, OSM Volunteer stevea wrote:
>
A hazy sort-of-emerging along with this is wider recognition that a proto_park 
thingy exists.  

And on Fri Apr 26 22:44:56 UTC 2019, Jmapb  replied:
Sounds like a good case for some lifecycle prefixes -- proposed:leisure=park or 
planned:leisure=park.

Excellent!  Yes, "lifecycle prefixes" are perfect for this.  My (careful, 
though I have "burned my fingers" using proposed before, and got spoken to by 
the DWG — the three of us had a nice lunch together — but that was years ago 
about a national mess I was cleaning up and we've straightened it out, as in 
WikiProject USBRS) experience with "proposed" is to use it on something which 
is "brought to fruition to, with or by public officials so responsible; clearly 
planned" at least and the funding is "programmed or likely to be."  That can 
get tricky, as sometimes funding lingers in limbo for a long time, like on 
California High Speed Rail (which I recently scaled back in OSM because our new 
Governor did).  But I certainly agree with your

Once park construction has begun, construction:leisure=park. And finally just 
leisure=park when it opens.

As clearly, construction only happens with funding.

Thank you for reminding us about lifecycle prefixes!

>
 I've seen kids on bikes go under fences and around things and treat "certain 
areas" just like an admittedly fully raw and completely undeveloped park, even 
though it isn't one.  Sometimes with respect, simply hiking around.  What is 
that?  Humans being human.  We should map those, accurately.

We have access=permissive, but I don't think a hole in a fence really
counts as "permissive." (I think de facto access to an area with no
fence/no signage/no enforcement *could* be called permissive.)

I, stevea, agree.  Thank you for your perspective and I hope it clarifies for 
others reading.

Other than that I can't think of any tags that would be applicable to
these sorts of situations. We tend to tag the regulations themselves,
not the extent to which they're adhered to. Certainly just calling it a
park because kids play there doesn't seem consistent with OSM standards.
We don't raise the speed limit in places where everyone speeds, or tag
bicycle=yes on ways where they're prohibited but frequently used.

No, I think leisure=playground aligns a bit more closely with "kids play here," 
though some people like snap-tight definitions, others consider things as much 
more elastic.  It's difficult to please everybody; semantics can be messy.  I'm 
glad we're better sharpening up leisure=park, it deserves more good discussion.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-ja] Feature Proposal - Voting - 投票-改定提案 Japan tagging/Road types Implies and Useful combination

[yuu hayashi]

hayashiです

[[Japan_tagging#Road_types]] の「Implies」と「Useful
combination」項目の改定提案のVoting(承認投票)を開始しました。

５月11日（土）までを投票期間としました。


投票は下記のURLへ

[改定提案 Proposed_Japan_tagging/Road_types]
https://wiki.openstreetmap.org/wiki/Proposed_Japan_tagging/Road_types

[現行のJapan_tagging#Road_types]
https://wiki.openstreetmap.org/wiki/Japan_tagging#Road_types

みなさまの 投票によるOSMへの貢献に期待しています。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Jmapb]

On 4/25/2019 8:39 PM, OSM Volunteer stevea wrote:


A hazy sort-of-emerging along with this is wider recognition that a proto_park thingy exists.  Put 
it in the planning departments "bin" for "department of parks budget, depending how 
much we convert protected_area into human-leisure-activity in the next budget or ten."  Maybe 
never, humanity and this planet can hope.  Hey, this could be a park someday if and as we improve 
it.


Sounds like a good case for some lifecycle prefixes --
proposed:leisure=park or planned:leisure=park. (No one seems to know
exactly what the difference is, or if one of these is further along in
the lifecycle than the other. Regardless, proposed:*=* is much more
widely used.)

Once park construction has begun, construction:leisure=park. And finally
just leisure=park when it opens.



I've seen kids on bikes go under fences and around things and treat "certain 
areas" just like an admittedly fully raw and completely undeveloped park, even 
though it isn't one.  Sometimes with respect, simply hiking around.  What is that?  
Humans being human.  We should map those, accurately.


We have access=permissive, but I don't think a hole in a fence really
counts as "permissive." (I think de facto access to an area with no
fence/no signage/no enforcement *could* be called permissive.)

Other than that I can't think of any tags that would be applicable to
these sorts of situations. We tend to tag the regulations themselves,
not the extent to which they're adhered to. Certainly just calling it a
park because kids play there doesn't seem consistent with OSM standards.
We don't raise the speed limit in places where everyone speeds, or tag
bicycle=yes on ways where they're prohibited but frequently used.

Jason


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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

 Doug Peterson  wrote (about "Parks in the 
USA..."):
> It is just that there is so much variety to deal with.

I agree, it proves frustrating from an OSM perspective.  I believe partly what 
happened is OSM started in the UK, where British English is spoken and 
"typically British" concepts entered the map with tags thusly derived, like 
leisure=park.  However and simultaneously, the well established American 
English sense of "park" ("a large area of land kept in its natural state for 
recreational use," my dictionary precedes that with "US") heavily affects how 
OSM USA contributors tag leisure=park.  This divergence from its OSM semantic 
(a British English idea of "smaller, urban, human-sculpted...) into US usage 
has gotten wider for many years.

BTW, this is partly a flame war I have been having for a week or two with 
another California user (starting with a question he asked on the leisure=park 
Talk page) and now seems to be improving in its tone and sanity (call it now 
"only" a brush fire).

What seems to be "shaking out" is that we US park-tagging contributors might 
think twice before NEWLY tagging leisure=park, though now there are a LOT of 
those in our map which likely should not be leisure=park, what many say is 
correct tagging.  So we have plenty of legacy tagging of USA parks which could 
benefit from examination and considering "Did this protected_area / 
national_park / nature_reserve / wide-open somewhat-natural recreation place 
get tagged leisure=park because of how Americans call LOTS of things parks, 
which isn't really how leisure=park is meant to be used?  Or is the 
leisure=park tag OK here, though many would say it's being stretched too far to 
correctly apply?  Many county parks are like this, though as Doug says, "there 
is so much variety" — yes, as many other "things" are in that bucket, too.

Greg Troxel  wrote (about "Parks in the USA..."):
> I don't understand this.

about my
>> I can see tag leisure=park persisting on a lot of county_parks for
>> some time (forever?), yet it seems OSM's worldwide view of "park"
>> excludes them (and we tag boundary=national_park on state and national
>> parks).

What I meant is partly what I say above to Doug:  that there is a lot of legacy 
leisure=park tagging in our map in the USA which persists, may for some time 
(by sheer vastness of number), and even when each and every questionable "park" 
is addressed by careful mappers who wish to do the right thing, there appears 
now to be a wide gulf between when the tag is seen to be appropriate, vs. 
inappropriate:  I circle back again to Doug's "there is so much variety to deal 
with."  There IS muddiness of how Americans use "park" to mean so much (and 
governments, via "Parks Departments" contribute), while our wiki definitions 
endeavor to be laser-focused.  I seek clarity, and slowly we appear to be 
getting there.  This won't get fixed overnight or soon, though, that is 
obvious, although I do believe that longer-term, things will heal towards 
better, more consistent tagging.

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

Re: [Talk-it-trentino] Talk-it-trentino Digest, Vol 79, Issue 3

[pietro marzani via Talk-it-trentino]

Il domenica 7 aprile 2019, 07:14:43 CEST, za...@gruppogrotte.it 
 ha scritto: 


>Ciao,
>da quanto hanno detto oltre a SAT contribuiscono
>allo stesso tavolo di lavoro diversi servizi della 
>provincia (foreste, turismo, protezione civile, ...).


>La delimitazione delle zone critiche dovrebbe 
>avvenire con geometrie tipo area, per includere 
>tutte le tipologie di percorso.

Oggi sull'Adige è apparso un articolo in cui si dice che l'assessore al turismo 
si lamenta dei ritardi nella pubblicazione di una cartina con la lista dei 
sentieri inagibili. Secondo voi vale la pena muoversi ufficialmente, chiedendo 
magari di poter partecipare al tavolo di lavoro istituito? Al momento ne fanno 
parte SAT, Enti parco, Consorzio dei Comuni, ASUC, Magnifica Comunità e 
Trentino Marketing. Penso che molti dei turisti che si muovono sui sentieri 
facciano uso dei nostri dati. Lo stesso sito di outdoor active  utilizzato da 
visittrentino e segnalato sopra da Zando fa routing sui nostri dati 
(https://www.outdooractive.com/it/routeplanner/). Non sarebbe male quindi 
vedere se c'è la possibilità di ottenere l'apertura dei dati per la 
pubblicazione, impegnandoci da parte nostra ad aggiornare il db con le 
informazioni rilasciate.
Ciao
Pietro

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

Re: [Talk-it] Uso della Strava Heatmap

[Any File]

On Thu, Apr 25, 2019 at 7:38 PM solitone  wrote:
>
> E’ corretto quello che si legge sulla Wiki di OSM [1], cioè che è possibile 
> utilizzare la Strava Heatmap per tracciare in OSM? C’è qualche documento 
> ufficiale che chiarisce questo aspetto?
>
> [1] 
> https://wiki.openstreetmap.org/wiki/Strava#Data_Permission_-_Allowed_for_tracing.21


Andando a guardare la history della pagina wiki trovo che il primo
riferimento a questa cosa è stato inserito nella versione del 21:35,
13 June 2014 visibile in
https://wiki.openstreetmap.org/w/index.php?title=Strava=1051329

in questa versione vi è un link ad una discussione via twitter
https://twitter.com/paulmach/status/455182880306905088

(nelle versioni successive questo link ad un certo punto sparisce)

Tuttavia, a leggere la discussione su twitter non mi pare affatto che
quello che viene detto possa essere presa come un'autorizzazione
formale.

AnyFile

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

Re: [Talk-it] nomi tra virgolette

[Any File]

Negli esempi che riporti,

> name=area picnic "il moro"

mi sembra di intuire che vengano usate le virgolette per isolare il vero nome

Se il nome vero è Il moro, allora usa semplicemente
name=Il moro
ed usa invece
name=area picnic il moro
(senza virgolette) se il nome con cui è conosciuto comprende anche area picnic

Non c'è scritto nella wiki italiana, ma in quella inglese in
https://wiki.openstreetmap.org/wiki/Key:name#Additional_data
trovi scritto

name=* tag is supposed to contain solely name, not to describe the
type or location of the object or one of its other properties

che posso tradurre in

Il tag name deve considerarsi come contenente soltanto il nome, non la
descrizione del tipo o la località dell'oggetto o di un'altra delle
sue proprietà.


Se il nome non è ufficiale, inseriscilo solo se è veramente
normalmente conosciuto con quel nome. (E sarebbe meglio se ci fosse
una fonte, anche se non ufficiale, da cui leggere come è scritto il
nome)

Se poi avessi bisogno di distinguere tra più nomi (perché
ufficialmente è chiamato in un modo, ma localmente  viene normalmente
indicato in altro modo) allora in
https://wiki.openstreetmap.org/wiki/IT:Key:name
e in
https://wiki.openstreetmap.org/wiki/Key:name
trovi diversi tag per specificare questa cosa. I tag utili sono ad
esempio loc_name, official_name, short_name, oltre ad alt_name ed
eventualmente, se la differenza è dovuta ad una diversa lingua,
specificare il diverso nome nelle diverse lingue (dialetti compresi)

Infine il tag inscription ha un uso completamente diverso (per
trascrivere cosa sulle targhe, tipo memoriali, lapidi, o altre cose)


AnyFile

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

Re: [OSM-talk] An Archive namespace for the OSM wiki?

[Richard]

On Fri, Apr 19, 2019 at 11:01:23PM +0200, Jochen Topf wrote:
> One problem with the wiki is that you can't find current stuff because
> of all the old stuff in there. Deleting helps. 

having the worst search engine of the whole internet isn't a good
reason to delete old content.
Its about time to admit the total failure of this search and inplement
it via google or other ones.

Richard

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

Re: [OSM-talk-fr] hauteur minimale de pont/tunnel

[osm . sanspourriel]

Oui je parle bien de maxheight.

Si un pont ou un tunnel n'a pas de panneau c'est normalement qu'il fait
plus de 4,30 m (4,75 m sur autoroute).

JB, on n'est pas dans le cas ou on n'a pas d'information, on a >=4,30 m.

Marc, merci ça me semble la meilleure solution. unsigned=maxheight et
maxheight=default peut bien dire >=4,30 m. Avec maxheight=default,
Osmose devrait déjà être content.

Je viens à cette occasion d'apprendre un autre tag : unsigned_ref pour
les numéros de routes non signalé sur le terrain. C'est le cas
typiquement des chemins d'exploitation.

Jean-Yvon

Le 26/04/2019 à 19:17, Gwenaël Jouvin via Talk-fr -
talk-fr@openstreetmap.org a écrit :

Par minimale, tu entends bien « hauteur maximale admissible » (maxheight=)?

Pour moi, quand il n’y a pas de panneau, c’est soit :
— un défaut de signalisation, ce qui est assez grave car quand ça coince… ça 
casse, et assez violemment :-p
— aucun besoin de signalisation car, comme sur autoroute, les ponts dépassent 
les hauteurs « communes » des véhicules.

Notons qu’en France, le code de la route ne définit pas de hauteur maximale 
autorisée pour les véhicules.

Des détails en page 3 de ce document consacré aux tunnels : 
http://www.cetu.developpement-durable.gouv.fr/IMG/pdf/CETU-Note_info_18_2009_cle718261.pdf


Pour les transports exceptionnels style charpente c’est autre chose, mais on 
s’arrange.


Gwenaël


Le 26/04/2019 à 18:46, osm.sanspourr...@spamgourmet.com a écrit :

Et si j'ai bien compris 4,75 m sur autoroute.

https://fr.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_limitation_de_hauteur_en_France

Le 26/04/2019 à 18:42, Jean-Yvon Landrac a écrit :

Bonjour,

Osmose couine quand un pont/tunnel n'a pas de hauteur minimale.

D'après le code de la route un tel ouvrage doit disposer d'un panneau indiquant 
la limite de hauteur si celle-ci est inférieure à 4,3 m.

S'il n'y a pas de panneau :
- vous prenez votre pentamètre et mesurez ;-)
- mettez 4,3 m. Pour les ponts standard ça doit être bon
- vous mettez un faux positif dans Osmose. Dommage car vous savez qu'il n'a au 
moins 4,3 m
- vous détruisez le pont, comme ça il n'y a pas de hauteur minimale ^^
- autre

Jean-Yvon


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


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

[OSM-talk-fr] Les sous-stations ferroviaires (SNCF et les autres)

[François Lacombe]

Salut à tous,

Suite au vote mouvementé du mois dernier, je soumets une nouvelle
proposition, restreinte aux sous-stations ferroviaires chargées d'alimenter
les trains en énergie.
La proposition d'origine était beaucoup plus importante et cela l'a
sûrement desservi. Il faut donc découper et le 1er opus est ici.

Le document, pour l'instant en RFC avant le vote suivant les commentaires
reçus
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Traction_substations_extension

Le but est d'introduire une clé plus simple (sans namespace) avec des
valeurs plus étoffées que yes/no pour indiquer si la sous-station produit
du courant continu ou pas
C'est utile pour mettre en cohérence l'appareillage installé à l'intérieur
(et aussi confronter ça aux voies alimentées).

Le vote de cette nouvelle clé pourra déboucher sur un projet du mois afin
de nettoyer le tagging des sites français (environ 2500 pour SNCF Réseau +
tous les transport en commun électriques) et proposer un jeu de données
avec une meilleure licence que celle choisie par la SNCF (saluons l'effort
par ailleurs)

N'hésitez pas à donner votre avis

Bon weekend

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

Re: [OSM-talk-fr] hauteur minimale de pont/tunnel

[marc marc]

maxheight renseigne l'info d'un panneau d'obligation.

donc ce que je ne ferrais pas, c'est mettre une valeur 4.3 ou autre
(certains utilisent maxheight:physical)

le wiki renseigne maxheight=default (encore faut il savoir que
c'est pas un panneau qui manque ou que le pont n'est pas au dessus ou
en dessus de la valeur habituel ce qui est une devinette hasardeuse)
et unsigned (au moins cette est clair)

sans lire le wiki, j'aurais simplement mis unsigned=maxheight et fait
un ticket pour que osmose ne pose pas la question quand même a renseigné
qu'il n'y a pas de panneau.

Le 26.04.19 à 18:46, osm.sanspourr...@spamgourmet.com a écrit :
> Et si j'ai bien compris 4,75 m sur autoroute.
> 
> https://fr.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_limitation_de_hauteur_en_France
> 
> Le 26/04/2019 à 18:42, Jean-Yvon Landrac a écrit :
>>
>> Bonjour,
>>
>> Osmose couine quand un pont/tunnel n'a pas de hauteur minimale.
>>
>> D'après le code de la route un tel ouvrage doit disposer d'un panneau 
>> indiquant la limite de hauteur si celle-ci est inférieure à 4,3 m.
>>
>> S'il n'y a pas de panneau :
>> - vous prenez votre pentamètre et mesurez ;-)
>> - mettez 4,3 m. Pour les ponts standard ça doit être bon
>> - vous mettez un faux positif dans Osmose. Dommage car vous savez 
>> qu'il n'a au moins 4,3 m
>> - vous détruisez le pont, comme ça il n'y a pas de hauteur minimale ^^
>> - autre
>>
>> Jean-Yvon
>>
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [OSM-talk-fr] hauteur minimale de pont/tunnel

[JB]

C'est une question ? C'est de l'humour ?
Pour remettre au clair, il me semble :
 - qu'on ne met pas de valeur quand on ne la connait pas
 - qu'on ne met pas de valeur clairement fausse
 - qu'on ne met pas de valeur juste pour faire plaisir à Osmose
JB.

Le 26/04/2019 à 18:42, osm.sanspourr...@spamgourmet.com a écrit :


Bonjour,

Osmose couine quand un pont/tunnel n'a pas de hauteur minimale.

D'après le code de la route un tel ouvrage doit disposer d'un panneau 
indiquant la limite de hauteur si celle-ci est inférieure à 4,3 m.


S'il n'y a pas de panneau :
- vous prenez votre pentamètre et mesurez ;-)
- mettez 4,3 m. Pour les ponts standard ça doit être bon
- vous mettez un faux positif dans Osmose. Dommage car vous savez 
qu'il n'a au moins 4,3 m

- vous détruisez le pont, comme ça il n'y a pas de hauteur minimale ^^
- autre

Jean-Yvon




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

Re: [OSM-talk-fr] Re: hauteur minimale de pont/tunnel

[Gwenaël Jouvin via Talk-fr]

Par minimale, tu entends bien « hauteur maximale admissible » (maxheight=)?

Pour moi, quand il n’y a pas de panneau, c’est soit :
— un défaut de signalisation, ce qui est assez grave car quand ça coince… ça 
casse, et assez violemment :-p
— aucun besoin de signalisation car, comme sur autoroute, les ponts dépassent 
les hauteurs « communes » des véhicules.

Notons qu’en France, le code de la route ne définit pas de hauteur maximale 
autorisée pour les véhicules.

Des détails en page 3 de ce document consacré aux tunnels : 
http://www.cetu.developpement-durable.gouv.fr/IMG/pdf/CETU-Note_info_18_2009_cle718261.pdf


Pour les transports exceptionnels style charpente c’est autre chose, mais on 
s’arrange.


Gwenaël


Le 26/04/2019 à 18:46, osm.sanspourr...@spamgourmet.com a écrit :
> Et si j'ai bien compris 4,75 m sur autoroute.
> 
> https://fr.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_limitation_de_hauteur_en_France
> 
> Le 26/04/2019 à 18:42, Jean-Yvon Landrac a écrit :
>>
>> Bonjour,
>>
>> Osmose couine quand un pont/tunnel n'a pas de hauteur minimale.
>>
>> D'après le code de la route un tel ouvrage doit disposer d'un panneau 
>> indiquant la limite de hauteur si celle-ci est inférieure à 4,3 m.
>>
>> S'il n'y a pas de panneau :
>> - vous prenez votre pentamètre et mesurez ;-)
>> - mettez 4,3 m. Pour les ponts standard ça doit être bon
>> - vous mettez un faux positif dans Osmose. Dommage car vous savez qu'il n'a 
>> au moins 4,3 m
>> - vous détruisez le pont, comme ça il n'y a pas de hauteur minimale ^^
>> - autre
>>
>> Jean-Yvon
>>
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [OSM-talk-fr] hauteur minimale de pont/tunnel

[osm . sanspourriel]

Et si j'ai bien compris 4,75 m sur autoroute.

https://fr.wikipedia.org/wiki/Panneau_de_signalisation_d%27une_limitation_de_hauteur_en_France

Le 26/04/2019 à 18:42, Jean-Yvon Landrac a écrit :


Bonjour,

Osmose couine quand un pont/tunnel n'a pas de hauteur minimale.

D'après le code de la route un tel ouvrage doit disposer d'un panneau
indiquant la limite de hauteur si celle-ci est inférieure à 4,3 m.

S'il n'y a pas de panneau :
- vous prenez votre pentamètre et mesurez ;-)
- mettez 4,3 m. Pour les ponts standard ça doit être bon
- vous mettez un faux positif dans Osmose. Dommage car vous savez
qu'il n'a au moins 4,3 m
- vous détruisez le pont, comme ça il n'y a pas de hauteur minimale ^^
- autre

Jean-Yvon

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

[OSM-talk-fr] hauteur minimale de pont/tunnel

[osm . sanspourriel]

Bonjour,

Osmose couine quand un pont/tunnel n'a pas de hauteur minimale.

D'après le code de la route un tel ouvrage doit disposer d'un panneau
indiquant la limite de hauteur si celle-ci est inférieure à 4,3 m.

S'il n'y a pas de panneau :
- vous prenez votre pentamètre et mesurez ;-)
- mettez 4,3 m. Pour les ponts standard ça doit être bon
- vous mettez un faux positif dans Osmose. Dommage car vous savez qu'il
n'a au moins 4,3 m
- vous détruisez le pont, comme ça il n'y a pas de hauteur minimale ^^
- autre

Jean-Yvon

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

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Marco Antonio]

Aun existen problemas al mapear elemento de transporte publico... markus
pregunta si se puede mejorar las etiquetas...

Abrazos,

Marco Antonio


On Fri, 26 Apr 2019 at 15:11, Markus  wrote:

> Hi all,
>
> I've added, updated and corrected several dozen public transportation
> routes in the past few years using the PTv2 scheme. As is the case
> with most route relations, they often break (e.g., because the course
> of a road or rails is modified, a new roundabout is built, a stop is
> displaced or simply by accident). However, with all the stop_positions
> and stop_areas, maintaining these routes and stops is very much
> time-consuming.
>
> There have been several ideas to simplify and improve public
> transportation mapping (e.g. [1] or [2]), however they either faced
> too much opposition or are inactive. Therefore I've worked out three
> different drafts for an improved public transportation scheme and
> would like your opinion. After that, i plan to write a full proposal
> for the option that got the most support.
>
> In order to better understand how I came up with the ideas below, I
> have first listed the deficiencies of the current public transport
> schemes:
>
> Deficiencies of PTv1:
>
>   * No separate route relation per direction and route variant.
>   * Platforms at stations cannot be added to route relations, which
> prevents a better routing.
>   * Stops (highway=bus_stop/railway=tram_stop) are often placed on the
> road or rail, which is not optimal for routing.
>
> Deficiencies of PTv2:
>
>   * public_transport=stop_position and public_transport=stop_area make
> mapping and maintaining complicated and time-consuming. Besides,
> public_transport=stop_position is unnecessary, as it can be calculated
> from public_transport=platform (which provide a more exact routing).
>   * Counter-intuitive public_transport=platform: its meaning depends
> on whether used on way/area (where it means a platform) or on node
> (where it means a waiting area w/o platform).
>   * Not possible to add transport mode tags (e.g. bus=yes) on
> public_transport=platform because they are also used to set access.
>
> Now for the possible solutions:
>
>   1. Sticking to PTv1 tags, but with separate route relations per
> direction/variant and by placing stops at the point where passengers
> wait. A stop with a platform get a railway/highway=platform way/area
> and a railway=tram_stop/highway=bus_stop node. (Except at stations, a
> stop_area relation is not required because the stop node is placed on
> the platform.) -- Advantage: Widely used tags, least retagging
> required. Disadvantage: A stop with a platform needs two elements (as
> railway/highway=platform + railway=tram_stop/highway=bus_stop can't be
> combined).
>
>   2. Sticking to PTv2 tags, but abandoning
> public_transport=stop_position and introducing a new transport_mode=*
> tag. -- Advantage: Only one element per stop. Disadvantage: The rather
> counter-intuitive public_transport=platform remains.
>
>   3. Abolishing public_transport=stop_position and
> public_transport=platform and introducing a new public_transport=stop
> tag (node/way/area) for the waiting area at stops, which can be
> combined with railway/highway=platform if the stop consists of a
> platform. Besides, introducing a new transport_mode=* tag. --
> Advantage: Only one element per stop, very flexible and clear.
> Disadvantage: Much retagging required.
>
> [1]:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Transport_modes_on_platforms_and_stations
> [2]:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport
>
> Thanks in advance for your replies.
>
> Best regards
>
> Markus
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

[Talk-transit] Ideas for a simplified public transportation scheme

[Markus]

Hi all,

I've added, updated and corrected several dozen public transportation
routes in the past few years using the PTv2 scheme. As is the case
with most route relations, they often break (e.g., because the course
of a road or rails is modified, a new roundabout is built, a stop is
displaced or simply by accident). However, with all the stop_positions
and stop_areas, maintaining these routes and stops is very much
time-consuming.

There have been several ideas to simplify and improve public
transportation mapping (e.g. [1] or [2]), however they either faced
too much opposition or are inactive. Therefore I've worked out three
different drafts for an improved public transportation scheme and
would like your opinion. After that, i plan to write a full proposal
for the option that got the most support.

In order to better understand how I came up with the ideas below, I
have first listed the deficiencies of the current public transport
schemes:

Deficiencies of PTv1:

  * No separate route relation per direction and route variant.
  * Platforms at stations cannot be added to route relations, which
prevents a better routing.
  * Stops (highway=bus_stop/railway=tram_stop) are often placed on the
road or rail, which is not optimal for routing.

Deficiencies of PTv2:

  * public_transport=stop_position and public_transport=stop_area make
mapping and maintaining complicated and time-consuming. Besides,
public_transport=stop_position is unnecessary, as it can be calculated
from public_transport=platform (which provide a more exact routing).
  * Counter-intuitive public_transport=platform: its meaning depends
on whether used on way/area (where it means a platform) or on node
(where it means a waiting area w/o platform).
  * Not possible to add transport mode tags (e.g. bus=yes) on
public_transport=platform because they are also used to set access.

Now for the possible solutions:

  1. Sticking to PTv1 tags, but with separate route relations per
direction/variant and by placing stops at the point where passengers
wait. A stop with a platform get a railway/highway=platform way/area
and a railway=tram_stop/highway=bus_stop node. (Except at stations, a
stop_area relation is not required because the stop node is placed on
the platform.) -- Advantage: Widely used tags, least retagging
required. Disadvantage: A stop with a platform needs two elements (as
railway/highway=platform + railway=tram_stop/highway=bus_stop can't be
combined).

  2. Sticking to PTv2 tags, but abandoning
public_transport=stop_position and introducing a new transport_mode=*
tag. -- Advantage: Only one element per stop. Disadvantage: The rather
counter-intuitive public_transport=platform remains.

  3. Abolishing public_transport=stop_position and
public_transport=platform and introducing a new public_transport=stop
tag (node/way/area) for the waiting area at stops, which can be
combined with railway/highway=platform if the stop consists of a
platform. Besides, introducing a new transport_mode=* tag. --
Advantage: Only one element per stop, very flexible and clear.
Disadvantage: Much retagging required.

[1]: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Transport_modes_on_platforms_and_stations
[2]: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Refined_Public_Transport

Thanks in advance for your replies.

Best regards

Markus

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

Re: [Talk-it] pannelli solari

[scratera]

..retifico
indoor=power



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

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

Re: [Talk-it] pannelli solari

[scratera]

Andrea Albani wrote
> Il giorno gio 25 apr 2019 alle ore 19:03 claudio62PG 

> claduc@

>  ha
> scritto:
> 
>> Capita di trovare case o altri edifici
>> con impianti fotovoltaici posti sopra il tetto
>> Come devono essere mappati?
>> (Possibilmente con esempi pratici)
>> Grazie
>> Claudio
>>
>>
> Come mapparli lo trovi qui [1]. Un esempio di mappatura qui [2]. Penso che
> con la presenza di location=roof l'uso di un tag aggiuntivo layer=1 sulla
> way del pannello possa essere superfluo, ma magari aiuta certi renderer.
> 
> 
> [1]
> https://wiki.openstreetmap.org/wiki/Tag:generator:source%3Dsolar#Rooftop_Solar_Panels
> [2] https://www.openstreetmap.org/way/416170483
> 
> ___
> Talk-it mailing list

> Talk-it@

> https://lists.openstreetmap.org/listinfo/talk-it

..a cui aggiungerei 
indoor=generator:source
level= 2 se la casa ha un piano e via dicendo



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

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

Re: [Talk-us] What is sold in Value Village? (shop=second_hand vs shop=clothes)

[Jmapb]

It's like a second-hand department store. I think shop=second_hand is
correct tagging in this case, barring any surveyed details about the
inventory of the particular branch. J

On 4/26/2019 9:55 AM, Evan Derickson wrote:

They sell a mix of everything...certainly a lot of clothes, but also
furniture, kitchenware, sporting goods, etc. You can see more details
at https://www.valuevillage.com/donate/what-we-take

On Fri, Apr 26, 2019 at 5:46 AM Mateusz Konieczny
mailto:matkoni...@tutanota.com>> wrote:

Is it a second hand shop, but what it is primarily selling?

Clothes? Or something else? Or is there no dominating product
and it is selling mix of everything?

I am asking as name-suggestion-index has it as shop=second_hand
without any indication of sold product and it seems to me that
shop=clothes + second_hand=only would be preferable tagging.

name-suggestion-index is used at least by iD and Vespucci so improving
it makes mapping a bit easier.

nsi issue: https://github.com/osmlab/name-suggestion-index/issues/2587
___
Talk-us mailing list
Talk-us@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-us



--
Evan Derickson
derickso...@gmail.com 

___
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] What is sold in Value Village? (shop=second_hand vs shop=clothes)

[Evan Derickson]

They sell a mix of everything...certainly a lot of clothes, but also
furniture, kitchenware, sporting goods, etc. You can see more details at
https://www.valuevillage.com/donate/what-we-take

On Fri, Apr 26, 2019 at 5:46 AM Mateusz Konieczny 
wrote:

> Is it a second hand shop, but what it is primarily selling?
>
> Clothes? Or something else? Or is there no dominating product
> and it is selling mix of everything?
>
> I am asking as name-suggestion-index has it as shop=second_hand
> without any indication of sold product and it seems to me that
> shop=clothes + second_hand=only would be preferable tagging.
>
> name-suggestion-index is used at least by iD and Vespucci so improving
> it makes mapping a bit easier.
>
> nsi issue: https://github.com/osmlab/name-suggestion-index/issues/2587
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
Evan Derickson
derickso...@gmail.com
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-ca] OpenStreetCam Waylen camera loan program

[John Marshall]

Hi All,

Is anyone interested in getting one of the loaner Waylen camera to collect
images for OpenStreetCam?

The program would be similar to what they are doing in the US
http://www.openstreetmap.us/2018/05/camera-lending-program/
 :

I was part of the Beta testing of the OSC Waylens,  and the system is far
superior to using a phone app or action camera like the Garmin Virb to
collect street level photo for OSM. Here is part of my trip to James Bay:
 http://openstreetcam.org/details/1264157/0/track-info
 The camera
automatically
uploads on wifi, I uploaded over 60 Gigs in about 8 hrs.

Post comments to the list or join our Slack Channel  https://osm-ca
.slack.com/messages/C36U69X18

If you are interested please let me know.

Cheers

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

Re: [talk-cz] Hruška - is it shop=convenience or shop=supermarket? Or maybe both?

[Mateusz Konieczny]

25 Apr 2019, 22:10 by xkomc...@centrum.cz:

>
> Hi Mateusz,
>
>
> Hruška is a brand name (Pear in the Czech language, but this is  
> irrelevant - it is just a name).
>
>
So my guess was correct :) ("gruszka" is the word for pear in Polish)

> Most of the times, shops running  under this brand should be tagged as 
> "convenience" (small shops in  villages), but some of them are larger and 
> shop=supermarket is  preferred tagging.
>
thanks, info added as
https://github.com/osmlab/name-suggestion-index/commit/e50e31819c73826971cc1bd35878b2c8f409327c
 


>
> Best regards,
>
>
> Jiri Komarek
>
> On 25. 04. 19 22:04, Mateusz Konieczny  wrote:
>
>>
>> * is shop=convenience sometimes preferable tagging for Hruška?
>>  * is shop=supermarket sometimes preferable tagging for Hruška?
>>  Is it maybe describing objects using the same name, butoperating 
>> under different brands.
>>  Or maybe it is a generic name (like amenity=restaurant
>> name=Restaurant) rather than a brand?
>>  Or maybe it is a valid name (like amenity=restaurantname=Bamboo), 
>> without an uniting brand?
>>  
>>  
>>  I am asking as I want to improve >> 
>> https://github.com/osmlab/name-suggestion-index/ 
>> 
>>  and I lack local knowledge how it should be tagged. Data fromthis 
>> project are
>>  used for example by iD and Vespucci.
>>  Users using this editors will be guided better during editing
>>  once current conflict between suggested tags will be fixed.
>>  In case that multiple tags can be correct depending on asituation
>>  it will be marked that both versions are OK.
>>
>> Sorry for using English.
>>
>> ___talk-cz mailing list>> 
>> talk-cz@openstreetmap.org >> 
>> https://lists.openstreetmap.org/listinfo/talk-cz 
>> >> 
>> https://openstreetmap.cz/talkcz 
>>

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

[Talk-us] What is sold in Value Village? (shop=second_hand vs shop=clothes)

[Mateusz Konieczny]

Is it a second hand shop, but what it is primarily selling?

Clothes? Or something else? Or is there no dominating product
and it is selling mix of everything?

I am asking as name-suggestion-index has it as shop=second_hand
without any indication of sold product and it seems to me that
shop=clothes + second_hand=only would be preferable tagging.

name-suggestion-index is used at least by iD and Vespucci so improving
it makes mapping a bit easier.

nsi issue: https://github.com/osmlab/name-suggestion-index/issues/2587
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [talk-cz] kontejnery na třízený odpad

[majka]

Já ale neříkám nic o tom, že by se to nemělo importovat.

Dívala jsem se na ta data, a je to ideál na "napůl import" - tj. upravit ta
data do podoby, co polkne JOSM, upravit tam (sloučit jednotlivé kontejnery
na totožném místě, a převést na jeden "velký" s několika druhy odpadu,
sloučit proti datům, podle Ortomapy zkontrolovat že umístění nových
odpovídá) a nahrát.  Záležitost maximálně na pár večerů, spíš si troufnu
říct, že na večer jediný, zvlášť díky té Ortofoto mapě Prahy - kontejnery
se podle ní dají zmapovat pohodlně i ručně, jsou vidět opravdu dobře. Proti
těm poštovním schránkám brnkačka.

Jenže jsem získala dojem, že Jitka s OSM nepracuje, nebo nepracuje natolik,
že tohle zvládne. A současná debata na import listu mě přesvědčuje o tom,
že to chce mít opravdu dobře srovnané pro to, aby nám to neodstřelili tam.
Teoreticky ty názory z import listu samozřejmě můžeme ignorovat - tj. jen
to tam oznámit, zahlásit "schváleno místní komunitou", a zdar. Je dost
lidí, kteří si jedou po svém, a nikam se neohlíží. Nebo to můžeme udělat
trochu pokoutně - domluvit se tady, a nikoho se neptat. Otázka je, jestli
to takhle chceme provozovat.

Majka

On Fri, 26 Apr 2019 at 10:11, Pavel Machek  wrote:

> Na druhou stranu... rucni mapovani ztizi nasledny import :-(. Pokud
> jsou pouzitelna data pro import, je lepsi to opravdu naimportovat...
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] kontejnery na třízený odpad

[Marián Kyral]

-- Původní e-mail --
Od: Pavel Machek 
Komu: OpenStreetMap Czech Republic 
Datum: 26. 4. 2019 10:16:33
Předmět: Re: [talk-cz] kontejnery na třízený odpad
"On Tue 2019-04-23 12:54:16, majka wrote:
> Nahrání všech kontejnerů (import) není věc, kterou bych doporučila
> nováčkovi.
>
> A to z jediného důvodu - je nutné si projít kolečkem na import listu -
> minimálně to tam oznámit, a dát cca 14 dní na případné připomínky - které
> skoro určitě přijdou. K tomu je nutné přesně popsat, jak se ta data budou
> převádět a jak se bude ověřovat jejich pravdivost a jak to sloučit proti
> tomu, co už v OSM je. U kontejnerů to není moc složité nebude, ale jistou
> zkušenost to chce mít.

Na druhou stranu... rucni mapovani ztizi nasledny import :-(. Pokud
jsou pouzitelna data pro import, je lepsi to opravdu naimportovat...
"



Ale stejně budeš muset řešit slučování s aktuálními daty. Pokud ne při
importu, tak třeba následně při aktualizacích. Navíc nikdy nemůžeš zaručit,
že tam někdo něco nepřidá ručně.




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

Re: [talk-cz] kontejnery na třízený odpad

[Pavel Machek]

On Tue 2019-04-23 12:54:16, majka wrote:
> Nahrání všech kontejnerů (import) není věc, kterou bych doporučila
> nováčkovi.
> 
> A to z jediného důvodu - je nutné si projít kolečkem na import listu -
> minimálně to tam oznámit, a dát cca 14 dní na případné připomínky - které
> skoro určitě přijdou. K tomu je nutné přesně popsat, jak se ta data budou
> převádět a jak se bude ověřovat jejich pravdivost a jak to sloučit proti
> tomu, co už v OSM je. U kontejnerů to není moc složité nebude, ale jistou
> zkušenost to chce mít.

Na druhou stranu... rucni mapovani ztizi nasledny import :-(. Pokud
jsou pouzitelna data pro import, je lepsi to opravdu naimportovat...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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