Re: [Talk-cz] Bylo: Import rozvoden v Praze / building=industrial -> building=service

[Jan Dudík]

Pozor na ten obvod -  občas jsou v katastru/RUIAN třeba kapličky, které
nemusí mít v obvodu ani těch 5 m.
u fragmentů zase může fragment sosedit s dalším a dohromady tvořit budovu.
Nehledě na 3D budovy...
---
Ing. Jan Dudík
projekce dopravních staveb
tel. 777082195


st 28. 11. 2018 v 22:47 odesílatel r00t  napsal:

> Ahoj,
>
> > Našlo mi to třeba tohle: https://www.openstreetmap.org/way/115219968-
> > majitelem jsou dle KM "Severomoravské vodovody a kanalizace Ostrava
> a.s.",
> > tedy zřejmě vodojem. To je taky building=service?
> Pokud je to jenom maly domecek tak "building=service", pro velke objekty
> (treba
> Podolska vodarna) potom "building=industrial".
> Jinak ten pozemek kolem, co je oploceny, tagovat "man_made=water_works"
> + "barrier=fence". Je mozne pridat "operator=X" podle toho komu vodarna
> patri.
> Pokud je to vodojem s klasickou nadrzi (vetsinou umely "kopec") tak ten se
> mapuje
> jako "man_made=reservoir_covered".
> Taky by se dalo pridat "pipeline=substation", zvlast pokud tam tudy treba
> vede
> nejaky dulezitejsi vodovod a treba uz je zmapovany.
> Kdyz jde o zdroj vody kde se ziskava ze zeme (casto pozemek s varovanim o
> ochrannem pasmu atd.) tak vlastni zdroj jako "man_made=water_well".
>
> A kdyz uz jsme u toho, tak dalsi podobne budovy a zarizeni mimo elektriny:
> - Stejna budka patrici plynovodu je taky "building=service", pozemek potom
> "pipeline=substation". Je mozne pridat dalsi tagy podle WIKI viz pipeline.
> Podobne je to pro dalsi *vody (ropovod,teplovod,... co jeste tu mame?).
> - Cisticka odpadnich vod: "man_made=wastewater_plant", mala budova asi
> opet "building=service" pokud to neni opravdu velka COV.
>
> To je asi vsechno co me ted napadlo ze se u nas v terenu vyskytuje...
>
>
> r00t
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Bylo: Import rozvoden v Praze / building=industrial -> building=service

[Marián Kyral]

-- Původní e-mail --
Od: majka 
Komu: talk-cz@openstreetmap.org
Datum: 28. 11. 2018 22:41:47
Předmět: Re: [Talk-cz] Bylo: Import rozvoden v Praze / building=industrial -
> building=service
"

Ahoj Mariáne,



já chápu ten rozdíl jako building=industrial je místo pro průmyslovou výrobu
- tj. spíš továrny, building=service jsou doslova budovy pro servisní /
technologická zařízení, do kterých jen občas někdo zajede. Tj. byla by to
jak většina technických zařízení vodáren, místní ČOV, tak i všechny ty
místní trafostanice. Z toho taky vychází ten nápad rozlišovat to podle
velikosti.




Idea pro Tracer byla asi takto:




RUIAN,  převáděné na budovu typu building=cokoli - pokud je obvod menší než
cca. 5 m -> jednoznačný fragment, resp. nebude budova, netrasovat. Mělo by
napadnout dotyčného samo, ovšem narážím na tyhle natrasované "budovy" (třeba
o šířce cca do 1 metru, nepravidelného tvaru) relativně často. Podle kvality
digitalizace jsou toho některé vsi plné a někteří z nás klikají na vše, co
se ukáže... Ideálně i místo natrasování nabídnout nahlášení jako chybná
budova. 





U těch building=industrial bych zkrátka vycházela z toho, že ty (hodně) malé
automaticky nejsou typ industrial, ale service. Jediný problém je někde u
těch hraničních rozměrů, kde si dovedu představit jak větší sídlištní
rozvodnu, tak i třeba hodně malou průmyslovou výrobnu. I tak mi ten dotaz
našel s poměrně velkou jistotou jen ta technická zařízení. U těch malých se
navíc podle umístění dá i poměrně přesně odhadnout, co to bude - v zástavbě
trafačka, někde v lese zařízení vodáren, kousek za vsí s největší
pravděpodobností ta místní ČOV. Ani přitom nemusím hledat majitele pozemku :
)





Všehochuť je u "budov občanské vybavenosti", tj. building=civic. Protože tam
jsou jako malé budovy zařazené jak autobusové zastávky, různé malé
přístřešky na skladování vybavení u fotbalových hřišť, tak i třeba menší
kaple, kapličky a zvoničky, takže bych řekla, že tam s tím udělat nic nejde.
Maximálně při přetrasování automaticky ponechávat případné existující
hodnoty tagu typu church/chapel při slučování tagů, a tu hodnotu "civic"
považovat za nadřazenou jen a pouze hodnotě "yes". 




Majka




"



Ahoj,

možná to bude trochu jednodušší, v RUIAN je těch typů více, všechny aktuálně
značíme jako building=industrial, takže pro začátek bude stačit jen upravit
mapování:




 1 | průmyslový objekt  - nechal bych building=industrial

16 | stavba technického vybavení - změnil bych na building=service

28 | stavba k využití vodní energie (vodní elektrárna) - building=?




U civic je to horší, tam je na výběr:

   5 | objekt občanské vybavenosti

   9 | stavba pro shromažďování většího počtu osob

  15 | stavba občanského vybavení




A když ta na to koukám, tak ještě bych asi rozdělil building=commercial.
Tohle jsou docela rozdílné volby:

10 | stavba pro obchod

14 | stavba pro administrativu




Marián













"









On Wed, 28 Nov 2018 at 21:16, Marián Kyral mailto:mky...@email.cz)> wrote:

"

On 28. 11. 18 20:43, Marián Kyral wrote:

"
On 28. 11. 18 20:01, Marián Kyral wrote:

"
On 28. 11. 18 17:57, majka wrote:

"

Zdravím všechny.



V rámci toho plánovaného importu se naťuknul jeden problém: většinu
technických budov máme (díky natrasování tracerem a převodem tagů jako
building=industrial místo building=service.



Zkusila jsem to dohledat přes overpass turbo dotazem s omezením velikosti,
resp. délky cesty (obvodu) na 50m(http://overpass-turbo.eu/s/E5S) . Jen v
Českých Budějovicích a okolí mi to vyhazuje přes 500 budov.




Velikost byla zkoušena na mě známé trafostanici, je to kapku víc než
považuji za jisté pro případné (polo-)automatické změny (je to např. budova
s půdorysem 10x15m). 




Pro mě to dává dvě otázky, z toho druhá je asi spíš na Mariána:




1. Nechceme vyhodit další "úkol", kde bychom se soustředili na tyhle budovy
a opravu jejich značení?




2. Nešel by upravit Tracer, aby při trasování podle RUIAN kontroloval i
velikost budovy, a u těch "podezřelých" buďto rovnou měnil značky na
building=service (zejména u těch malých - malé trafostanice, budovy ČOV a
podobně) nebo vyhodil dialog, kde by dotyčný musel sám rozhodnout? Klidně
bych to nechala tím obvodem, pokud je to jednodušší.





"
Ahoj,
můžeš hodit do placu pár příkladů, abych mrknul přímo do dat? Kontrolovat
obvod určitě půjde, jen si nejsem jist, zda to nepřinese více škody než
užitku.
"
Pardon, než jsem došel sem, tak jsem zapomněl, že jsi výš dala odkaz na
overpass turbo :-D Zkusil jsem projet okolí a asi na tom něco bude. Ale nic
neslibuji. Teď jsem se pustil do schránek v okrese Opava ;-)

"
Našlo mi to třeba tohle: https://www.openstreetmap.org/way/115219968
(https://www.openstreetmap.org/way/115219968) - majitelem jsou dle KM
"Severomoravské vodovody a kanalizace Ostrava a.s.", tedy zřejmě vodojem. To
je taky building=service?

Marián


___
Talk-cz mailing list

Re: [Talk-us] Fwd: Trunk versus motorway

[Albert Pundt]

I always tag based on the actual access control. At the end of a clear
freeway, continue the motorway tagging to the first intersection or
driveway, or if the road becomes single-carriageway and isn't a super-2 (a
controlled-access freeway in which only one carriageway is constructed with
accommodation for the second later). There is no "except for the
intersections."

If a road like that has enough intersections spaced throughout its length,
it should be tagged as trunk, perhaps with expressway=yes. Though with just
two or three intersections nearby in the middle of a freeway (for example
the handful of remaining intersections in the mostly-freeway section of US
29 in Maryland), I'd tag it as trunk only between the intersections and
make the rest motorway.

The Tisdale Parkway should absolutely be tagged as motorway starting from
the Gilcrease intersection southward. Gilcrease should be motorway as well
from where it becomes dual-carriageway. The remaining sections of each of
these roads should be tagged as trunk.

On Thu, Nov 29, 2018 at 12:31 AM Nathan Mills  wrote:

> I think this is a good general rule. In the instant case, the tagging
> should change at the point where the grass median ends northbound, IMO.
> That marks a definite change in the physical character of the road. I
> believe it was tagged like that when the carriageways were first split
> after the TIGER import, but I might be misremembering.
>
> -Nathan
>
>
>
> On November 29, 2018 12:01:58 AM EST, Evin Fairchild 
> wrote:
>>
>> What?! I haven't contradicted myself at all. I already said in my initial
>> response (the one that I sent to only you by mistake) that in cases where
>> there's an at grade intersection sandwiched in between two interchanges,
>> the road should be marked as trunk in between. Other than that case, a road
>> should be motorway all the way to the at-grade intersection, as is the case
>> with the Tisdale Parkway.
>>
>> On Wed, Nov 28, 2018 at 8:11 PM Paul Johnson  wrote:
>>
>>> On Wed, Nov 28, 2018 at 10:02 PM Evin Fairchild 
>>> wrote:
>>>
 Nobody is saying that we should tag as motorways a road with a surface
 intersection. I don't understand what it is that we're saying that's
 causing you to come to that conclusion. We are simply saying that the
 first surface intersection that a road comes across is where the motorway
 should change to trunk.

>>>
>>> You've contradicted yourself in that statement.
>>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


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

Re: [OSM-talk-fr] Les voies vertes

[JB]

Le 28/11/2018 à 21:03, marc marc a écrit :

Est-ce que ton refus de la vision quasi généralisé vient-il du fait
qu'il y a une donneur d'ordre qui a un besoin de rendu particulier ?
Quasi-généralisé ? Tu bases le sondage sur ton sentiment personnel que 
tu projettes à la communauté française ?

Je trouve la vision d'Antoine sur les voies vertes très juste.
Je trouve malvenu de suggérer que son point de vue est lié à son 
travail. Antoine a toujours demandé l'avis de la communauté avant de 
cartographier des situations particulières et a toujours été transparent 
dans ses démarches.
Quand au sujet du rendu, ceux qui pratiquent devraient savoir que c'est 
un argument sans valeur. À partir du moment où tu fais un rendu 
spécialisé, tu es obligé de traiter toutes les manières de tagguer 
possible, pas uniquement la sienne ou sa préférée.

JB.


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

Re: [Talk-us] Fwd: Trunk versus motorway

[Nathan Mills]

I think this is a good general rule. In the instant case, the tagging should 
change at the point where the grass median ends northbound, IMO. That marks a 
definite change in the physical character of the road. I believe it was tagged 
like that when the carriageways were first split after the TIGER import, but I 
might be misremembering.

-Nathan



On November 29, 2018 12:01:58 AM EST, Evin Fairchild  
wrote:
>What?! I haven't contradicted myself at all. I already said in my
>initial
>response (the one that I sent to only you by mistake) that in cases
>where
>there's an at grade intersection sandwiched in between two
>interchanges,
>the road should be marked as trunk in between. Other than that case, a
>road
>should be motorway all the way to the at-grade intersection, as is the
>case
>with the Tisdale Parkway.
>
>On Wed, Nov 28, 2018 at 8:11 PM Paul Johnson 
>wrote:
>
>> On Wed, Nov 28, 2018 at 10:02 PM Evin Fairchild 
>> wrote:
>>
>>> Nobody is saying that we should tag as motorways a road with a
>surface
>>> intersection. I don't understand what it is that we're saying that's
>>> causing you to come to that conclusion. We are simply saying that
>the
>>> first surface intersection that a road comes across is where the
>motorway
>>> should change to trunk.
>>>
>>
>> You've contradicted yourself in that statement.
>>

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

Re: [Talk-us] Forest Routes

[Michael Patrick]

I'm not familiar with OSM routing, but these roads enter and cross some of
the most inhospitable mountainous terrain in the United States.

Some, like the 101 mile long Magruder Corridor (
https://www.fs.usda.gov/Internet/FSE_DOCUMENTS/stelprdb5109483.pdf ) are
only open a few months of the year, or never open at all ( especially when
fire fighting is going on ). So it would behoove the mapper to research the
routes in detail. Elk Mountain Pass in Wyoming is  11,171ft and has 14
passes over 10,000+ alone.

Even if they are 'open' the weather can make conditions untenable in a
heart beat. The US Forest Service sometimes requires that an axe,shovel and
a bucket be carried in your vehicle when traversing on USFS property and
roads during fire season and states follow the lead of the USFS.

Hmmm ... maybe there needs to be 'Local Knowledge' tag.

Sigh. Makes me home sick.

Michael

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

Re: [Talk-us] Fwd: Trunk versus motorway

[Evin Fairchild]

What?! I haven't contradicted myself at all. I already said in my initial
response (the one that I sent to only you by mistake) that in cases where
there's an at grade intersection sandwiched in between two interchanges,
the road should be marked as trunk in between. Other than that case, a road
should be motorway all the way to the at-grade intersection, as is the case
with the Tisdale Parkway.

On Wed, Nov 28, 2018 at 8:11 PM Paul Johnson  wrote:

> On Wed, Nov 28, 2018 at 10:02 PM Evin Fairchild 
> wrote:
>
>> Nobody is saying that we should tag as motorways a road with a surface
>> intersection. I don't understand what it is that we're saying that's
>> causing you to come to that conclusion. We are simply saying that the
>> first surface intersection that a road comes across is where the motorway
>> should change to trunk.
>>
>
> You've contradicted yourself in that statement.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-cat] Adreces de Port de Barcelona

[Jan Esquerra]

Bon dia Enric,

entenc que al què es refereix que heu fet 'malament' és que per un banda
heu fet servir etiquetes que no són consensuades a OpenStreetMap (com per
exemple ST_NAME=Carrer de l'Atlàntic) i que heu afegit nodes amb l'etiqueta
building=yes quan ja hi ha un polígon definint l'edifici en qüestió.

El que seria més correcte és que tota la informació anés associada al
polígon que defineix l'edifici fent servir etiquetes consensuades a OSM per
tal que tothom les pugui interpretar correctament. Per exemple, en comptes
del ST_NAME=Carrer de l'Atlàntic que heu posat hauria de ser addr:street=Carrer
de l'Atlàntic, i etc.
De com etiquetar trobaràs més informació a wiki.openstreetmap.org

No obstant això, a OSM no està pas prohibit fer servir etiquetes no
consensuades si tenen alguna finalitat o utilitat, tot i que m'ha semblat
que no és el cas. En cas de fer-ho, és un bona pràctica exposar una
proposta d'etiqueta i valors a la comunitat per tal d'explicar-la, i que
s'obri un debat per millorar-la si s'escau i consensuar-la.

Igualment, no està del tot malament fer servir un node per definir
informació d'un edifici, com per exemple l'adreça. Segons el meu parer, ho
faig quan l'edifici és molt extens i/o té varies entrades, per facilitar
l'enrutament. Aleshores els nodes és localitzen a les entrades i s'afegeix
l'etiqueta entrance=main, entrance=yes. L'etiqueta building=yes va al
polígon.

Salut i bona feina

Jan

Missatge de Enric Rodellas  del dia dc., 28 de
nov. 2018 a les 15:50:

> Hola
> Avui el Raf m'ha fet notar que hem fet alguna (o moltes) coses incorrectes
> en pujar les adreces del Port de Barcelona.
> No n'erem conscients i no hem estat al cas de:
> https://www.openstreetmap.org/changeset/48757646
>
> Però tampoc he matat cap elefant.
> Agrairé qualsevol recomanació i ajuda.
> Ens ho mirem i intentarem reparar-ho o revertir-ho.
>
> Gràcies per l'ajuda (i comprensió i paciència amb els ignorants)
> i gràcies a la comunitat openstreet. Al Port de Barcelona l'utilitzem pel
> routing terrestre, que en algunes coses és millor que el Google Maps
> --
> Enric Rodellas
> enricrodel...@gmail.com
> ___
> Talk-cat mailing list
> Talk-cat@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cat
>
___
Talk-cat mailing list
Talk-cat@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cat

Re: [Talk-us] Fwd: Trunk versus motorway

[Paul Johnson]

On Wed, Nov 28, 2018 at 10:02 PM Evin Fairchild  wrote:

> Nobody is saying that we should tag as motorways a road with a surface
> intersection. I don't understand what it is that we're saying that's
> causing you to come to that conclusion. We are simply saying that the
> first surface intersection that a road comes across is where the motorway
> should change to trunk.
>

You've contradicted yourself in that statement.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: Trunk versus motorway

[Mike N]

On 11/28/2018 10:36 PM, Nathan Mills wrote:
Adding the intersection did not change the character of the road south 
of the Gilcrease extension or the rights of adjacent landowners, so I 
don't see any particular reason to reclassify that segment.


  If we're looking for a generalized rule, consider that there may be 
many miles of motorway between the last exit and the next at-grade 
intersection, so it would make sense to keep that section as motorway.


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

Re: [Talk-us] Fwd: Trunk versus motorway

[Joseph Eisenberg]

In California some roads have signs that say “End Freeway”, about 1/2 mile
before the first intersection, eg I-8 in San Diego.
On Thu, Nov 29, 2018 at 1:04 PM Evin Fairchild  wrote:

> Nobody is saying that we should tag as motorways a road with a surface
> intersection. I don't understand what it is that we're saying that's
> causing you to come to that conclusion. We are simply saying that the
> first surface intersection that a road comes across is where the motorway
> should change to trunk.
>
> -Evin
>
> On Nov 28, 2018 7:42 PM, "Paul Johnson"  wrote:
>
> On Wed, Nov 28, 2018 at 9:36 PM Nathan Mills  wrote:
>
>> Unless there have been significant changes since I moved away, it should
>> be tagged motorway between the IDL and the light at Apache/Gilcrease
>> Extension. Before the Gilcrease was extended west of US-75, the Tisdale
>> should have been tagged entirely as motorway. Adding the intersection did
>> not change the character of the road south of the Gilcrease extension or
>> the rights of adjacent landowners, so I don't see any particular reason to
>> reclassify that segment.
>>
>
> Right, but where are we getting that motorways have surface intersections
> now?
> ___
> 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] Fwd: Trunk versus motorway

[Evin Fairchild]

Nobody is saying that we should tag as motorways a road with a surface
intersection. I don't understand what it is that we're saying that's
causing you to come to that conclusion. We are simply saying that the first
surface intersection that a road comes across is where the motorway should
change to trunk.

-Evin

On Nov 28, 2018 7:42 PM, "Paul Johnson"  wrote:

On Wed, Nov 28, 2018 at 9:36 PM Nathan Mills  wrote:

> Unless there have been significant changes since I moved away, it should
> be tagged motorway between the IDL and the light at Apache/Gilcrease
> Extension. Before the Gilcrease was extended west of US-75, the Tisdale
> should have been tagged entirely as motorway. Adding the intersection did
> not change the character of the road south of the Gilcrease extension or
> the rights of adjacent landowners, so I don't see any particular reason to
> reclassify that segment.
>

Right, but where are we getting that motorways have surface intersections
now?
___
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] Fwd: Trunk versus motorway

[Paul Johnson]

On Wed, Nov 28, 2018 at 9:36 PM Nathan Mills  wrote:

> Unless there have been significant changes since I moved away, it should
> be tagged motorway between the IDL and the light at Apache/Gilcrease
> Extension. Before the Gilcrease was extended west of US-75, the Tisdale
> should have been tagged entirely as motorway. Adding the intersection did
> not change the character of the road south of the Gilcrease extension or
> the rights of adjacent landowners, so I don't see any particular reason to
> reclassify that segment.
>

Right, but where are we getting that motorways have surface intersections
now?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: Trunk versus motorway

[Nathan Mills]

Unless there have been significant changes since I moved away, it should be 
tagged motorway between the IDL and the light at Apache/Gilcrease Extension. 
Before the Gilcrease was extended west of US-75, the Tisdale should have been 
tagged entirely as motorway. Adding the intersection did not change the 
character of the road south of the Gilcrease extension or the rights of 
adjacent landowners, so I don't see any particular reason to reclassify that 
segment.

North of that, either trunk or primary would be equally reasonable.

-Nathan

On November 28, 2018 10:21:41 PM EST, Paul Johnson  wrote:
>On Wed, Nov 28, 2018 at 9:00 PM Evin Fairchild 
>wrote:
>
>> I think you're misrepresenting the discussion. People are simply
>saying
>> that the motorway destination should extend all the way to the first
>at
>> grade intersection, rather than the interchange prior to the at grade
>> intersection. Personally, I agree with this. The only exception would
>be if
>> there's an at grade intersection sandwiched between two interchanges.
>In
>> that case there should be a stretch of trunk in between the two
>> interchanges.
>>
>
>Right, but motorways are grade-separated, fully controlled, dual
>carriageways.  Throw in an at grade intersection, that's no longer
>grade
>separated.  That's not a freeway anymore, that's an expressway.
>Expressways are semi-controlled and do have surface intersections,
>though
>some or even most may be grade separated.
>
>
>> Further, I strongly disagree with the way the Tisdale was originally
>> tagged, (the entire thing, even the obvious freeway sections were
>> originally trunk) because if we followed Paul's logic everywhere,
>most odd
>> numbered 3 digit interstates would have to be tagged as trunk.
>>
>
>Well, let's talk about that.  There's quite a few out there that
>probably
>shouldn't be motorways, but instead motorway_link or trunk.  I 90 west
>of I
>5 is mapped a motorway right now but it's just a spiderweb of ramps to
>the
>Seattle Bus Tunnel, 5th Avenue, Seattle Boulevard, 4th Avenue, and
>Martinez.  Rationale for going from the US 412 interchange being that's
>the
>last (only, really) major junction along Tisdale with an unambiguous
>motorway.

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

Re: [Talk-us] Fwd: Trunk versus motorway

[Paul Johnson]

On Wed, Nov 28, 2018 at 9:00 PM Evin Fairchild  wrote:

> I think you're misrepresenting the discussion. People are simply saying
> that the motorway destination should extend all the way to the first at
> grade intersection, rather than the interchange prior to the at grade
> intersection. Personally, I agree with this. The only exception would be if
> there's an at grade intersection sandwiched between two interchanges. In
> that case there should be a stretch of trunk in between the two
> interchanges.
>

Right, but motorways are grade-separated, fully controlled, dual
carriageways.  Throw in an at grade intersection, that's no longer grade
separated.  That's not a freeway anymore, that's an expressway.
Expressways are semi-controlled and do have surface intersections, though
some or even most may be grade separated.


> Further, I strongly disagree with the way the Tisdale was originally
> tagged, (the entire thing, even the obvious freeway sections were
> originally trunk) because if we followed Paul's logic everywhere, most odd
> numbered 3 digit interstates would have to be tagged as trunk.
>

Well, let's talk about that.  There's quite a few out there that probably
shouldn't be motorways, but instead motorway_link or trunk.  I 90 west of I
5 is mapped a motorway right now but it's just a spiderweb of ramps to the
Seattle Bus Tunnel, 5th Avenue, Seattle Boulevard, 4th Avenue, and
Martinez.  Rationale for going from the US 412 interchange being that's the
last (only, really) major junction along Tisdale with an unambiguous
motorway.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk] Sophox is back to life

[Yuri Astrakhan]

Thanks to a kind donation by Elastic (of Elasticsearch fame), we now have a
much cleaner and more stable Sophox service.

Sophox is an RDF database that contains:
* All of OSM data without geometries
* All of OSM Metadata (keys, well known tags, etc) as defined in OSM Wiki
items (with all translations)
* Recent Wikipedia's pageviews statistics
* All polygon geometries that are tagged with the wikidata tag
* A query-driven tag editor

Sophox no longer contains a copy of the Wikidata itself, but it now allows
federation - subqueries that can get data from other SPARQL sources.  Many
example queries in OSM wiki will need to be updated.

Try it (use the blue "play" button on the left side to run the query)
*  http://tinyurl.com/y9tzyonj -- metadata prefix search for keys/tags with
description containing words like "ramp*"

Github: https://github.com/sophox/sophox

If you know SPARQL, please help with examples and documentation.

P.S. Thank you for all your emails asking about it, and offering to help.
Without you, it wouldn't have materialized!
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-us] Fwd: Trunk versus motorway

[Evin Fairchild]

-- Forwarded message -
From: Evin Fairchild 
Date: Wed, Nov 28, 2018, 6:42 PM
Subject: Re: [Talk-us] Trunk versus motorway
To: Paul Johnson 


I think you're misrepresenting the discussion. People are simply saying
that the motorway destination should extend all the way to the first at
grade intersection, rather than the interchange prior to the at grade
intersection. Personally, I agree with this. The only exception would be if
there's an at grade intersection sandwiched between two interchanges. In
that case there should be a stretch of trunk in between the two
interchanges.

Further, I strongly disagree with the way the Tisdale was originally
tagged, (the entire thing, even the obvious freeway sections were
originally trunk) because if we followed Paul's logic everywhere, most odd
numbered 3 digit interstates would have to be tagged as trunk. Frankly,
I've wanted to change this road from trunk to motorway in the past, but
I've avoided doing so because this is Paul's home turf and I felt I'd just
be shaking a hornet's nest.


-Evin (compdude)

On Wed, Nov 28, 2018, 6:19 PM Paul Johnson  Can I get some voice of reason in
> https://www.openstreetmap.org/changeset/64919426?  There seems to be
> quite a few people (and one AARoads forum troll egging it on) that are
> trying to propel the idea that motorways have at-grade intersections, which
> is obviously incorrect.
> ___
> 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] Trunk versus motorway

[Bryan Housel]

Can’t a motorway begin or end at an at-grade intersection though?

What you did by classifying it “trunk” back to the Apache Street interchange 
just looks weird.
Sorry, but I have to disagree, and would leave it as a motorway up to 
Gilcrease, then trunk beyond that point.

For comparison, our Garden State Parkway in NJ ends at an at grade intersection 
at Exit 0 in Cape May, and I think this is fine.
https://www.openstreetmap.org/node/4904630893#map=17/38.96139/-74.90345 


Thanks, Bryan



> On Nov 28, 2018, at 9:18 PM, Paul Johnson  wrote:
> 
> Can I get some voice of reason in 
> https://www.openstreetmap.org/changeset/64919426 
> ?  There seems to be quite 
> a few people (and one AARoads forum troll egging it on) that are trying to 
> propel the idea that motorways have at-grade intersections, which is 
> obviously incorrect.
> ___
> 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] Trunk versus motorway

[Paul Johnson]

Can I get some voice of reason in
https://www.openstreetmap.org/changeset/64919426?  There seems to be quite
a few people (and one AARoads forum troll egging it on) that are trying to
propel the idea that motorways have at-grade intersections, which is
obviously incorrect.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] R: Re: Tablet con Osmand al posto del navigatore per il 118

[Fra Mauro]

Sulla domanda 1)
La risposta è NO.
Però una volta al mese sarebbe consigliabile scaricare gli aggiornamenti, 
possibilmente via wifi.
Considera che quelli standard : 
- escono agli inizi del mese.
- Sono disponibili per le singole regioni italiane
- Sono disponibili in doppia versione: solo strade e completa. Non ricordo se i 
civici sono inclusi nella versione soli strade

Il 25 Novembre 2018 10:51:06 CET, "riccardopastoc...@alice.it" 
 ha scritto:
>Mi spiego meglio
>
>per osmand il caricamento della mappa (marche) lo faccio tramite wi-fi
>a casa quindi nessun problema,poi prendo il tablet e lo piazzo in
>ambulanza per sempre fino alla sua durata di vita che spero sia lunga.
>Da questo momento in poi non ho wi-fi neanche quando rientriamo in
>postazione fissa.
>Quindi la domanda è: 1) ogni volta che imposto il navigatore osmand e
>parto per la destinazione, mi consuma byte? Per quello che ho
>capito la risposta è NO ... giusto?2) ogni volta che imposto il
>navigatore Google Map e parto per la destinazione, mi consuma byte?  
>Qui non ho capito la risposta ...
>3) Come faccio a capire quale Tablet ha il migliore ricevitore GPS...
>quali dati devo verificare?
>4) Spippolando su interner mi sono andato a vedere i Tablet da 7
>pollici che stanno entro i €150 e ho scoperto che ho poche
>alternative.Anzi direi una alternativa, il Samsung Galaxy Tab A 7.0
>t285
>Non potendo spendere più di € 150 ... Avete alternative più valide? 
>In poche parole deve essere una scheggia nell'elaborazione dei dati di
>osmand, deve avere una buona ricezione GPS 
>Tutto il resto: fotocamere, estetica, leggerezza non mi serve a niente
>GrazieRiccardo
>
>
>
>  Messaggio originale
> 
> Da: cascaf...@gmail.com
> 
> Data: 24-nov-2018 18.36
> 
>A: "riccardopastocchi", "openstreetmap list
>- italiano"
> 
>Ogg: Re: [Talk-it] Tablet con Osmand al posto del navigatore per il 118
> 
>
> 
>
> 
>  
>Google maps ha la possibilità di scaricare prima le zone per l'utilizzo
>senza internet, mentre Osmand è nato per essere utilizzato in qs modo.
>Ovviamente queste cose le puoi dare sia con sim che in wifi.
>  
>  
>   
>
>  
>  
>Non saprei quanti megabyte possa richedere GM per una regione, Osmand
>per il Friuli circa 100.
>  
>  
>   
>
>  
>  
>Osmand consuma dati solo se gli richiedi via menu di
>aggiornare/scaricare una mappa. Le recenti versioni possono consumare
>dati nel caso selezioni un POI e chiedi i dettagli: tra questi possono
>esserci foto mapillary di qualche mega.
>  
>  
>   
>
>  
>  
>Su quale tablet non saprei, ma se Osmand dovesse avere problemi di
>prestazioni, possono accadere con mappe molto ricche: in tal caso ci
>sono spesso a disposizione versioniversioni di mappe con solo le
>strade oppure le fai te :-)
>  
>  
>   
>
>  
>  
>Piuttosto che le prestazioni, verifica quale sia iltablet col migliore
>ricevitore GPS, sopratutto se il servizio è nei tipici paesini italici.
>  
>  
>   
>
>  
>  
>   
>
>  
>  
>   
>
>  
>  
>   
>
>  
>  
>   
>
>   
>
> Il sab 24 nov 2018, 11:18 
> riccardopastoc...@alice.it <
> riccardopastoc...@alice.it> ha scritto:
> 
>
>
>
> Salve a tutti sono Riccardo del 118, ho un dilemma.
> 
>Credo che sia ormai acquisito che il modo migliore di utilizzare Osmand
>sia in un dispositivo android,
> 
> 
>Detto questo visto che ci sono molti autisti che hanno iphon, ho
>pensato che la cosa migliore da fare sia 
> 
> 
>  utilizzare un tablet android al posto del navigatore.
> 
> 
>  
>
> 
> 
>1) Siete tutti d'accordo o c'è chi me lo sconsiglia? Eventualmente
>perchè?
> 
> 
>2) Utilizzando il tablet solo come navigatore Osmand e in rari casi
>Google Map, 
> 
> 
>(perché a volte ci capita di andare fuori zona di competenza
>territoriale, dove ancora non sono arrivato a mappare)
> 
> 
>il tablet ha comunque bisogno della Sim? E ogni volta che mi connetto a
>Osmand o Google map mi consuma GigaByte? Eventualmente quanti ?
> 
> 
>5) Il tablet rimarrà sempre in ambulanza, quindi sempre attaccato alla
>corrente, può creare problemi?
> 
> 
>  
>
> 
> 
>6) Rimanendo in una spesa compresa nei 150€ quale tablet mi
>consigliate?
> 
> 
>  6 pollici (al massimo7)
> 
> 
>  Deve durare nel tempo
> 
> 
>  Non deve essere lento (da cosa dipende la lentezza?)
> 
> 
>  Non si deve imballare
> 
> 
>  
>
> 
> 
>  Grazie per i vostri preziosi consigli
> 
> 
>  Riccardo
> ___
> 
> Talk-it mailing list
> 
>
> Talk-it@openstreetmap.org
> 
>
> https://lists.openstreetmap.org/listinfo/talk-it
> 
>
>
>   
>  
> 
> 

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Estrarre percorso

[antonyb]

Si dati open li prendo da lì, ma purtroppo non li aggiornano molto
frequentemente.

Mi piacerebbe sapere dove prendono i dati aggiornati il sito muoversi a
roma...
Spero mi sbaglio ma no mi sembra che sia utile quel link che hai postato...



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

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

Re: [OSM-talk-fr] Les voies vertes

[Antoine Riche]

Le 28/11/2018 à 21:03, marc marc a écrit :

Est-ce que ton refus de la vision quasi généralisé vient-il du fait
qu'il y a une donneur d'ordre qui a un besoin de rendu particulier ?


La question a le mérite d'être franche et c'est très bien :)

Voici quelques photos qui montrent la diversité de ce qu'on peut trouver 
derrière un panneau C115 : https://album.zaclys.com/,a75,74529. Il y a 
certes une photo dans le lot qui n'a plus son panneau, mon hypothèse est 
que la voie verte a été déclassée vu l'état de la chaussée un peu plus 
loin, même si elle est encore répertoriée chez l'AF3V 
(https://www.af3v.org/-Fiche-VVV-.html?voie=265).


S'il n'y avait pas le panneau C115, celle d'Angers serait 
highway=footway, celle de Nantes Route de Saint-Joseph un path, celle de 
Carquefou un track, celle de Saint-Michel-Chef-Chef une unclassified, 
celle des bords de Loire peut-être un service. La présence d'un panneau 
C115 définit la réglementation qui s'applique à la voie, pas son 
"importance et sa structure physique" pour reprendre la définition du 
tag highway 
(https://wiki.openstreetmap.org/wiki/FR:Key:highway#Description).


Bien sûr on peut distinguer finement les différents cas de figures avec 
les tags surface et width, mais ces tags sont assez rares et pas si 
faciles à appliquer. Et je trouve étrange de devoir changer la valeur de 
highway si l'aménageur pose un panneau C115 ou le retire.


Bien sûr ajouter le tag traffic_sign sur un way n'est pas simple car il 
faut savoir où commence et finit la voie verte. Mais ce n'est pas 
différent pour les tags maxspeed et surface, et c'est pour cela que je 
laisse ce tag au cyclo-mappeur qui mappe à vélo et pas depuis son salon ;)


Pour répondre très franchement à ta question, la volonté d'ajouter le 
tag traffic_sign est d'arriver à identifier les Voies vertes déclarées 
comme telles par l'aménageur. Pas pour un donneur d'ordre en particulier 
mais de manière générale, afin que OSM lui permette de répondre à la 
question "Où sont mes voies vertes ?". La combinaison highway=path + 
foot=designated + bicycle=designated n'est pas fiable, elle risque de 
laisser de côté nombre de voies vertes et d'inclure nombre de faux positifs.


Pour le reste, ma volonté est que la description des aménagements 
cyclables sur OSM soit la plus riche et la plus simple possible. Si la 
présence d'un seul panneau définit la valeur de 3 tags on perd en 
richesse. Si ajouter un panneau de réglementation implique de modifier 
le tag principal (qui définit l'importance et la structure physique de 
la voie), on perd en simplicité. Et en perdant la simplicité on risque 
de perdre nombre de contributeurs.


Antoine.



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

Re: [talk-au] Ferry Routes mapping in NSW

[Simon Slater]

On Monday, 26 November 2018 11:43:27 AM AEDT Sigurjón Gísli Rúnarsson wrote:
> I think so long as there's an active ferry route running between two
> 
> > terminals then it should have a route=ferry[1] connecting them, roughly
> > following the actual geometry the route normally takes. Where you have a
> > ferry route that sometimes has a few variants, eg. sometimes skips a
> > terminal, or sometimes goes to a different wharf, then that can be
> > accounted for using the ferry route relation.
> > 
> > As the wiki points out[1], this could be a simple way, or a route
> > relation[2]

I made changes to this ferry route https://www.openstreetmap.org/way/627090817 
a while ago, but OSRM is still not routing traffic across the punt.  Can 
anyone see what I missed?

-- 
Regards
Simon Slater

Registered Linux User #463789 @ http://linuxcounter.net

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

Re: [Talk-it] Estrarre percorso

[Maurizio Napolitano]

On Wed, Nov 28, 2018 at 2:20 PM antonyb  wrote:
>
> Vorrei sapere se è possibile estrarre un percorso di una linea da questo
> sito: https://muoversiaroma.it/it/linea?numero=64 ho cercato nel codice
> della pagina ma non ho trovato nulla... in genere prendo i percorsi da
> questo sito gli open data https://romamobilita.it/it ma in caso di
> cambiamenti di percorsi i dati venogno aggiornati dopo qualche giorno. Mi
> chiedo anche dove avranno questi dati più aggiornati.

all'inizio ho pensato che la richiesta fosse per estrarre i dati da
openstreetmap, poi ho visto invece che si chiede di fare "scraping".
Gli opendata del trasporto di Roma si trovano qui
https://romamobilita.it/it/tecnologie/open-data

In ogni caso qui c'è il json che stai cercando
https://muoversiaroma.it/jsons/routes/64.json

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

Re: [Talk-it] surface: concrete_plates o paving_stones

[liste DOT girarsi AT posteo DOT eu]

Il 28/11/18 16:22, demon.box ha scritto:

ciao in questo caso:





con mattonelle di medie dimensioni in cemento con una piccola distaziatura
(fuga) tra una e l'altra:

surface=concrete_plates

oppure

superface=paving_stones?

grazie



Per me la prima, però taggata in questa maniera, come da wiki:

surface=concrete:plates


La seconda la vedo più un tipo come quello delle mattonelle dei cortili, 
come questo per esempio:


https://www.ferraribk.it/images/ferraribk/img_pag_prodotti/vintage/castelveccho_01.jpg


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

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

Re: [Talk-gb-westmidlands] Saturday Mapping

[Chris Dunne]

I could do Saturday I think but have realised I'm going out for a meal in
the evening so won't be up for one in the daytime. What time were
you thinking of meeting? It's either a approx 1hr 45 cycle for me or 30 min
drive depending on the weather.

I've not done a vast deal of mapping, but a  couple of past outings.

Chris

On Wed, 28 Nov 2018 at 16:15, Brian Prangle  wrote:

> H Gareth
>
> Shame about that. I'm now not able to do the 8th Dec so I'll turn out this
> Sat. There's a new pub there called the Tuning Fork. Anybody else up for
> this?
>
> Regards
>
> Brian
>
> On Sun, Nov 25, 2018 at 5:53 PM Gareth L  wrote:
>
>> I’m rather local to this, but sadly I am away both weekends!
>> It’s worthwhile doing. Google maps and Apple maps are lagging quite far
>> behind on Rugby’s redevelopments/developments. Surprisingly, an entire
>> retail park is missing from both.
>>
>>
>> Gareth
>>
>>
>> Get Outlook for iOS 
>>
>>
>> From: Brian Prangle 
>> To: talk-gb-westmidlands 
>> Subject: [Talk-gb-westmidlands] Saturday Mapping
>> Message-ID:
>> 
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi everyone
>>
>> It's a been a while since we met in November and I agrred to to get some
>> dates for a mapping dayin Warwicks(with a pub lunch). I propose either
>> Saturday 1 Dec or 8 Dec and I propose we go to the new village being built
>> on the old Rugby Radio Station site which is called Houlton
>> 
>>
>> It's a massive development( over 6,000 homes - partially complete) with
>> the
>> first residents moving in a year ago and also a new primary school
>> operational. Currently it's shown as a construction site with a few
>> service
>> roads. If folk can get to me reasonably quickly I'll see if I can drum up
>> some local interest
>>
>> Regards
>>
>> Brian
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.openstreetmap.org/pipermail/talk-gb-westmidlands/attachments/20181122/841874d1/attachment-0001.html
>> >
>>
>> --
>>
>> Subject: Digest Footer
>>
>> ___
>> Talk-gb-westmidlands mailing list
>> Talk-gb-westmidlands@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>>
>>
>> --
>>
>> End of Talk-gb-westmidlands Digest, Vol 121, Issue 1
>> 
>> ___
>> Talk-gb-westmidlands mailing list
>> Talk-gb-westmidlands@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>>
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

Re: [Talk-cz] Bylo: Import rozvoden v Praze / building=industrial -> building=service

[r00t]

Ahoj,

> Našlo mi to třeba tohle: https://www.openstreetmap.org/way/115219968-
> majitelem jsou dle KM "Severomoravské vodovody a kanalizace Ostrava a.s.",
> tedy zřejmě vodojem. To je taky building=service?
Pokud je to jenom maly domecek tak "building=service", pro velke objekty (treba
Podolska vodarna) potom "building=industrial".
Jinak ten pozemek kolem, co je oploceny, tagovat "man_made=water_works"
+ "barrier=fence". Je mozne pridat "operator=X" podle toho komu vodarna patri.
Pokud je to vodojem s klasickou nadrzi (vetsinou umely "kopec") tak ten se 
mapuje
jako "man_made=reservoir_covered".
Taky by se dalo pridat "pipeline=substation", zvlast pokud tam tudy treba vede
nejaky dulezitejsi vodovod a treba uz je zmapovany.
Kdyz jde o zdroj vody kde se ziskava ze zeme (casto pozemek s varovanim o
ochrannem pasmu atd.) tak vlastni zdroj jako "man_made=water_well".

A kdyz uz jsme u toho, tak dalsi podobne budovy a zarizeni mimo elektriny:
- Stejna budka patrici plynovodu je taky "building=service", pozemek potom
"pipeline=substation". Je mozne pridat dalsi tagy podle WIKI viz pipeline.
Podobne je to pro dalsi *vody (ropovod,teplovod,... co jeste tu mame?).
- Cisticka odpadnich vod: "man_made=wastewater_plant", mala budova asi
opet "building=service" pokud to neni opravdu velka COV.

To je asi vsechno co me ted napadlo ze se u nas v terenu vyskytuje...


r00t


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

[Talk-cz] Mizející CHKO v ČR

[xkomc...@centrum.cz]

Ahoj,


před pár dny jsem zaznamenal, že zmizela CHKO Jeseník. Neměl jsem zrovna 
čas to nějak řešit, ale dnes jsem si všiml další "zmizelé" CHKO - Bílé 
Karpaty. Letmý pohled do historie napověděl, že změnu provedl Adam 
Hauner, stejně tak jako u několika dalších (viz 
https://www.openstreetmap.org/user/Adam Hauner/history ). Komentář u 
prvních dvou editací "novější tag pro chráněná území", u těch dalších 
"konzistence s ostatními CHKO v ČR". Je pravda, že 
boundary=protected_area je novější a "správnější", má to ale pár háčků:


1) změnu provedl pouze u zhruba poloviny CHKO, druhá je postaru 
"boundary=national_park"


2) pokud by se měl začít používat tento tag, změnit by se měly i národní 
parky (pro ně boundary=protected_area taky platí)


3) CHKO se nyní nevykreslují na mapě openstreetmap.org


Co teď s tím? Pošťouchnout Adama, aby doupravil všechny CHKO a národní 
parky (do stavy, kdy všechny mají "boundary=protected_area")? Vrátil 
změny zpět (požádat jej o to či případně provést svépomocí)? Jiný návrh?



Jirka Komárek


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

Re: [Talk-cz] Bylo: Import rozvoden v Praze / building=industrial -> building=service

[majka]

Ahoj Mariáne,

já chápu ten rozdíl jako building=industrial je místo pro průmyslovou
výrobu - tj. spíš továrny, building=service jsou doslova budovy pro
servisní / technologická zařízení, do kterých jen občas někdo zajede. Tj.
byla by to jak většina technických zařízení vodáren, místní ČOV, tak i
všechny ty místní trafostanice. Z toho taky vychází ten nápad rozlišovat to
podle velikosti.

Idea pro Tracer byla asi takto:

RUIAN,  převáděné na budovu typu building=cokoli - pokud je obvod menší než
cca. 5 m -> jednoznačný fragment, resp. nebude budova, netrasovat. Mělo by
napadnout dotyčného samo, ovšem narážím na tyhle natrasované "budovy"
(třeba o šířce cca do 1 metru, nepravidelného tvaru) relativně často. Podle
kvality digitalizace jsou toho některé vsi plné a někteří z nás klikají na
vše, co se ukáže... Ideálně i místo natrasování nabídnout nahlášení jako
chybná budova.

U těch building=industrial bych zkrátka vycházela z toho, že ty (hodně)
malé automaticky nejsou typ industrial, ale service. Jediný problém je
někde u těch hraničních rozměrů, kde si dovedu představit jak větší
sídlištní rozvodnu, tak i třeba hodně malou průmyslovou výrobnu. I tak mi
ten dotaz našel s poměrně velkou jistotou jen ta technická zařízení. U těch
malých se navíc podle umístění dá i poměrně přesně odhadnout, co to bude -
v zástavbě trafačka, někde v lese zařízení vodáren, kousek za vsí s
největší pravděpodobností ta místní ČOV. Ani přitom nemusím hledat majitele
pozemku :)

Všehochuť je u "budov občanské vybavenosti", tj. building=civic. Protože
tam jsou jako malé budovy zařazené jak autobusové zastávky, různé malé
přístřešky na skladování vybavení u fotbalových hřišť, tak i třeba menší
kaple, kapličky a zvoničky, takže bych řekla, že tam s tím udělat nic
nejde. Maximálně při přetrasování automaticky ponechávat případné
existující hodnoty tagu typu church/chapel při slučování tagů, a tu hodnotu
"civic" považovat za nadřazenou jen a pouze hodnotě "yes".

Majka


On Wed, 28 Nov 2018 at 21:16, Marián Kyral  wrote:

> On 28. 11. 18 20:43, Marián Kyral wrote:
>
> On 28. 11. 18 20:01, Marián Kyral wrote:
>
> On 28. 11. 18 17:57, majka wrote:
>
> Zdravím všechny.
>
> V rámci toho plánovaného importu se naťuknul jeden problém: většinu
> technických budov máme (díky natrasování tracerem a převodem tagů jako
> building=industrial místo building=service.
>
> Zkusila jsem to dohledat přes overpass turbo dotazem s omezením velikosti,
> resp. délky cesty (obvodu) na 50m  . Jen
> v Českých Budějovicích a okolí mi to vyhazuje přes 500 budov.
>
> Velikost byla zkoušena na mě známé trafostanici, je to kapku víc než
> považuji za jisté pro případné (polo-)automatické změny (je to např. budova
> s půdorysem 10x15m).
>
> Pro mě to dává dvě otázky, z toho druhá je asi spíš na Mariána:
>
> 1. Nechceme vyhodit další "úkol", kde bychom se soustředili na tyhle
> budovy a opravu jejich značení?
>
> 2. Nešel by upravit Tracer, aby při trasování podle RUIAN kontroloval i
> velikost budovy, a u těch "podezřelých" buďto rovnou měnil značky na
> building=service (zejména u těch malých - malé trafostanice, budovy ČOV a
> podobně) nebo vyhodil dialog, kde by dotyčný musel sám rozhodnout? Klidně
> bych to nechala tím obvodem, pokud je to jednodušší.
>
>
> Ahoj,
> můžeš hodit do placu pár příkladů, abych mrknul přímo do dat? Kontrolovat
> obvod určitě půjde, jen si nejsem jist, zda to nepřinese více škody než
> užitku.
>
>
> Pardon, než jsem došel sem, tak jsem zapomněl, že jsi výš dala odkaz na
> overpass turbo :-D Zkusil jsem projet okolí a asi na tom něco bude. Ale nic
> neslibuji. Teď jsem se pustil do schránek v okrese Opava ;-)
>
>
> Našlo mi to třeba tohle: https://www.openstreetmap.org/way/115219968 -
> majitelem jsou dle KM "Severomoravské vodovody a kanalizace Ostrava a.s.",
> tedy zřejmě vodojem. To je taky building=service?
>
> Marián
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-be] arlon - osm - training courses

[Pierre Parmentier]

 Hello Joost,

Why such assistance at the EPN Arlon? Some people came because it was 'La
Semaine numérique' of the Fédération Wallonie-Bruxelles and the head of the
EPN in Arlon, Martine Delbrouck, was very quickly convinced of the interest
of the subject. I also informed some Luxembourg members of SGR about the
existence of this training.

About iD. Yes, we talked about this editor. But I tried to convince the
participants to use a more complete tool. I hope that three or four of them
will contribute in the long run. We will see if they attend our quarterly
meeting around Arlon!

We didn't ad a look at MapContrib. Nor to HOT! Time flies when you want to
make sure everyone is doing all the work with their computer!

Next step is on 15 January 2019.

Thank you Joost for your interest in this case.

Regards.

Pierre P.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-us] Forest Routes

[Paul Johnson]

On Wed, Nov 28, 2018 at 2:51 PM Eric H. Christensen  wrote:

> On Wednesday, November 28, 2018 9:49 AM, Martijn van Exel 
> wrote:
>
> > I think you are right. It would be good if we can arrive at a common
> > prefix and document it on the wiki. 'FS' makes sense. Perhaps even a new
> > page dedicated to roads that are maintained directly by federal agencies
> > (NPS, USDA, others?) would make sense. I'd be happy to help set it up.
>
> I've noticed that some of these "roads" are showing FS, FT, and another F
> something when they were imported.  Should all these ways use 'FS' or
> should they use the different prefix based upon what type of way they are
> (outside of the proper tagging for the way)?
>

Note that the Forest Service uses the same numbering scheme for trails,
with 2 digit Forest Service routes being the main routes (be it a hiking
trail or a road), 3 digit and 4 digit routes being of lesser importance in
the overall network and usually being referred to as National Forest
Development or NFD trails/roads.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Forest Routes

[Paul Johnson]

On Wed, Nov 28, 2018 at 3:58 AM Minh Nguyen 
wrote:

> On 2018-11-20 08:57, Martijn van Exel wrote:
> > When I map these roads I include the FS number (just the number) as a
> > ref, since that is how they are signposted in the field.
>
> I think the ref tag on the ways should have a prefix and not just
> consist of a bare number. Otherwise, it's just as ambiguous for data
> consumers as the (123) refs all over New Jersey, since the U.S. doesn't
> have a highway tag that corresponds one-for-one with forest routes.
>

Agreed, I tend to follow the Forest Service's own convention of going with
FS for 2 digit routes and NFD (National Forest Development) for 3 and 4
digit routes.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Uso del tag Disused e rendering

[Sergio Manzi]

Mi correggo sul fatto che, secondo il wiki, una aerialway non può essere una 
relation (/chissà perché... e comunque in 76 la pensano come me!/), ma tutto il 
resto non cambia...

On 2018-11-28 21:33, Sergio Manzi wrote:
>
> Ciao!
>
> Guarda che stiamo dicendo (+ o -) la stesse cose:
>
>   * se la seggiovia non c'è più, non deve esistere nel DB.
>   * se i piloni ci sono, i piloni devono stare nel DB (ed essere visualizzati)
>   * se c'è tutto, sarebbe meglio che tutto, piloni, stazioni a valle e a 
> monte, cavo (come way) e l'insieme del tutto come realation 
> aerialway=chair_lift, stesse nel DB
>   * però, bene o male, il più delle volte si traccia solo la way della 
> seggiovia (/corrispondente al cavo/) e non sono del tutto in disaccordo, 
> sennò dovremmo mappare anche le traversine delle ferrovie.
>   * ma se l'elemento qualificante della seggiovia (/il cavo 
> portante/trainante/) non c'è più, la way la cancello e se voglio essere un 
> bravo cittadino magari mappo i piloni che prima non avevo mappato.
>   * se la seggiovia non è in uso è "disused", *non *access=no, che è tutto un 
> altro concetto.
>   * se hai mappato le stazioni a monte e a valle e sono chiuse, lì, *oltre al 
> disused:*, ci può stare pure bene l'access=no (/perché così so che in caso di 
> mal tempo non potrò usarle come rifugio/)
>
> Sergio
>
>
> On 2018-11-28 21:11, Daniele Forsi wrote:
>> Il giorno mer 28 nov 2018 alle ore 20:50 Sergio Manzi ha scritto:
>>
>>> P.S.: ... e se della seggiovia tolgono il cavo e lasciano i piloni, devo 
>>> mappare i singoli piloni come disused:man_made=pilone_o_quelchelè, perché 
>>> la seggiovia in quanto la struttura non esiste più, ma i piloni sì, anche 
>>> se non usati (disused)
>> no, è questo il punto di partenza sbagliato di questo thread, cioè
>> volere usare un tag solo per due cose diverse: l'oggetto fisico e il
>> suo uso, come il "buco" di una cava o di una miniera e l'attività di
>> estrazione, e il pilone è sempre un pilone (aerialway=pylon) finché
>> non viene distrutto è la seggiovia che non esiste più, non c'è più
>> un'amenity, ma non è il caso iniziale che è:
>>
>>> skilift ubicato nel comune di Pragelato (TO) sul terreno esiste tutto, 
>>> piloni, cavi, costruzioni alla partenza e all'arrivo, ma non è più 
>>> funzionante da qualche anno
>> in questo caso secondo me che vivo al mare :-D è uno skilift "chiuso"
>> e quindi giustamente è meglio se si vede su una mappa per sciatori, io
>> metterei aerialway:access=no sulla ex-partenza[1] e amenity=drag_lift
>> sulla way senza tag disused
>>
>> [1] https://wiki.openstreetmap.org/wiki/Key:aerialway
>>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] Forest Routes

[Eric H. Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

‐‐‐ Original Message ‐‐‐
On Wednesday, November 28, 2018 9:49 AM, Martijn van Exel  
wrote:

> I think you are right. It would be good if we can arrive at a common
> prefix and document it on the wiki. 'FS' makes sense. Perhaps even a new
> page dedicated to roads that are maintained directly by federal agencies
> (NPS, USDA, others?) would make sense. I'd be happy to help set it up.

I've noticed that some of these "roads" are showing FS, FT, and another F 
something when they were imported.  Should all these ways use 'FS' or should 
they use the different prefix based upon what type of way they are (outside of 
the proper tagging for the way)?

Eric
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsFcBAEBCAAQBQJb/v+kCRCAdqveAkuz0QAA5hEQAIdx+eIbu5v2xtBQ7CJD
4FvUPKcr/lWhmh+wKkKiKI9uiXBcxiTgsgGWg/3YzOrBIwr6EYsgprcL5BEt
Uga+MeJXEeg3UvChcUjTS77cFHC3btjJWSVkVIfvunIvtbqln7uOp8xibmgy
zaHf6Xyi8mf0erIr1A55+XTHGGS0nRgM2AyHzLA3U9Y0O/8ejs1e2Dp4C/sN
iCXDxOItONtx6cfg00wsqYHCKaKGfng77dORF5IF6jYkxP/tQPBOk9gCPcvW
NAEE1jLMOo3A1F9pc0U3UsmHwujxwfpG3DXV2QiSsjoJ1Bmhh2vD3Q+wmTyK
cb9PjCYqkQzG8K7nCIrvJddtc+za5+tWhpVX+n30gOrlOgmNyctnAF/OKrAa
wi3WJKfbIFka6/T+lEulBz6XtHxMx2hH3XzOBlvT0UpShbyyxEDELMzM4gB0
SnKzwN9bvOUP2wq+9TjEemSQx0Goo2BjGuVBoWt0Dgv0Q47A8W6c6/kws+2o
kn7CTE2OXzRHzi2sKcXu+OWQTNHEhxmITvDBZGnEi/gHCAyJDX4AcdEhQMnF
CW0U4IcKlanEXFUbgmr+qrMI9yZsEX2uM+HZzGfx7xOqQpLihudxjgPAi+wG
Y+VY+mC85i7dwqxd4o/f9cj7BpuXygN5ZZcNrDmCY1Flde1Eq/1pFYFcnZJr
qilr
=swxb
-END PGP SIGNATURE-


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

Re: [Talk-it] Uso del tag Disused e rendering

[Sergio Manzi]

Ciao!

Guarda che stiamo dicendo (+ o -) la stesse cose:

  * se la seggiovia non c'è più, non deve esistere nel DB.
  * se i piloni ci sono, i piloni devono stare nel DB (ed essere visualizzati)
  * se c'è tutto, sarebbe meglio che tutto, piloni, stazioni a valle e a monte, 
cavo (come way) e l'insieme del tutto come realation aerialway=chair_lift, 
stesse nel DB
  * però, bene o male, il più delle volte si traccia solo la way della 
seggiovia (/corrispondente al cavo/) e non sono del tutto in disaccordo, sennò 
dovremmo mappare anche le traversine delle ferrovie.
  * ma se l'elemento qualificante della seggiovia (/il cavo 
portante/trainante/) non c'è più, la way la cancello e se voglio essere un 
bravo cittadino magari mappo i piloni che prima non avevo mappato.
  * se la seggiovia non è in uso è "disused", *non *access=no, che è tutto un 
altro concetto.
  * se hai mappato le stazioni a monte e a valle e sono chiuse, lì, *oltre al 
disused:*, ci può stare pure bene l'access=no (/perché così so che in caso di 
mal tempo non potrò usarle come rifugio/)

Sergio


On 2018-11-28 21:11, Daniele Forsi wrote:
> Il giorno mer 28 nov 2018 alle ore 20:50 Sergio Manzi ha scritto:
>
>> P.S.: ... e se della seggiovia tolgono il cavo e lasciano i piloni, devo 
>> mappare i singoli piloni come disused:man_made=pilone_o_quelchelè, perché la 
>> seggiovia in quanto la struttura non esiste più, ma i piloni sì, anche se 
>> non usati (disused)
> no, è questo il punto di partenza sbagliato di questo thread, cioè
> volere usare un tag solo per due cose diverse: l'oggetto fisico e il
> suo uso, come il "buco" di una cava o di una miniera e l'attività di
> estrazione, e il pilone è sempre un pilone (aerialway=pylon) finché
> non viene distrutto è la seggiovia che non esiste più, non c'è più
> un'amenity, ma non è il caso iniziale che è:
>
>> skilift ubicato nel comune di Pragelato (TO) sul terreno esiste tutto, 
>> piloni, cavi, costruzioni alla partenza e all'arrivo, ma non è più 
>> funzionante da qualche anno
> in questo caso secondo me che vivo al mare :-D è uno skilift "chiuso"
> e quindi giustamente è meglio se si vede su una mappa per sciatori, io
> metterei aerialway:access=no sulla ex-partenza[1] e amenity=drag_lift
> sulla way senza tag disused
>
> [1] https://wiki.openstreetmap.org/wiki/Key:aerialway
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Tablet con Osmand al posto del navigatore per il 118

[naca84]

Io sono vari anni che uso osmand come navigatore, l'ho preferito rispetto ad 
altri perché quando vado fuori dall'Italia, stacco la connessione dei dati e 
vado senza problemi. 
Mi ha portato in tutta Europa ed è stato sempre preciso.
L'unico problema è sorto negli ultimi due aggiornamenti, la navigazione non mi 
passa più in modalità di movimento, ma rimane bloccata a modalità bussola, 
problema molto fastidioso specialmente quando si sta nei centri abitati.

Ciao Carlo

Il 24 Novembre 2018 11:18:10 CET, "riccardopastoc...@alice.it" 
 ha scritto:
>Salve a tutti sono Riccardo del 118, ho un dilemma.Credo che sia ormai
>acquisito che il modo migliore di utilizzare Osmand sia in un
>dispositivo android,Detto questo visto che ci sono molti autisti che
>hanno iphon, ho pensato che la cosa migliore da fare sia utilizzare un
>tablet android al posto del navigatore.
>1) Siete tutti d'accordo o c'è chi me lo sconsiglia? Eventualmente
>perchè?2) Utilizzando il tablet solo come navigatore Osmand e in rari
>casi Google Map, (perché a volte ci capita di andare fuori zona di
>competenza territoriale, dove ancora non sono arrivato a mappare)il
>tablet ha comunque bisogno della Sim? E ogni volta che mi connetto a
>Osmand o Google map mi consuma GigaByte? Eventualmente quanti ?5) Il
>tablet rimarrà sempre in ambulanza, quindi sempre attaccato alla
>corrente, può creare problemi?
>6) Rimanendo in una spesa compresa nei 150€ quale tablet mi
>consigliate?6 pollici (al massimo7)Deve durare nel tempoNon deve essere
>lento (da cosa dipende la lentezza?)Non si deve imballare
>Grazie per i vostri preziosi consigliRiccardo

-- 
Inviato dal mio dispositivo Android con Email. Perdonate la brevità.___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Bylo: Import rozvoden v Praze / building=industrial -> building=service

[Marián Kyral]

On 28. 11. 18 20:43, Marián Kyral wrote:

On 28. 11. 18 20:01, Marián Kyral wrote:

On 28. 11. 18 17:57, majka wrote:

Zdravím všechny.

V rámci toho plánovaného importu se naťuknul jeden problém: většinu 
technických budov máme (díky natrasování tracerem a převodem tagů 
jako building=industrial místo building=service.


Zkusila jsem to dohledat přes overpass turbo dotazem s omezením 
velikosti, resp. délky cesty (obvodu) na 50m 
 . Jen v Českých Budějovicích a 
okolí mi to vyhazuje přes 500 budov.


Velikost byla zkoušena na mě známé trafostanici, je to kapku víc než 
považuji za jisté pro případné (polo-)automatické změny (je to např. 
budova s půdorysem 10x15m).


Pro mě to dává dvě otázky, z toho druhá je asi spíš na Mariána:

1. Nechceme vyhodit další "úkol", kde bychom se soustředili na tyhle 
budovy a opravu jejich značení?


2. Nešel by upravit Tracer, aby při trasování podle RUIAN 
kontroloval i velikost budovy, a u těch "podezřelých" buďto rovnou 
měnil značky na building=service (zejména u těch malých - malé 
trafostanice, budovy ČOV a podobně) nebo vyhodil dialog, kde by 
dotyčný musel sám rozhodnout? Klidně bych to nechala tím obvodem, 
pokud je to jednodušší.




Ahoj,
můžeš hodit do placu pár příkladů, abych mrknul přímo do dat? 
Kontrolovat obvod určitě půjde, jen si nejsem jist, zda to nepřinese 
více škody než užitku.


Pardon, než jsem došel sem, tak jsem zapomněl, že jsi výš dala odkaz 
na overpass turbo :-D Zkusil jsem projet okolí a asi na tom něco bude. 
Ale nic neslibuji. Teď jsem se pustil do schránek v okrese Opava ;-)




Našlo mi to třeba tohle: https://www.openstreetmap.org/way/115219968 - 
majitelem jsou dle KM "Severomoravské vodovody a kanalizace Ostrava 
a.s.", tedy zřejmě vodojem. To je taky building=service?


Marián

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

Re: [Talk-it] Uso del tag Disused e rendering

[Daniele Forsi]

Il giorno mer 28 nov 2018 alle ore 20:50 Sergio Manzi ha scritto:

> P.S.: ... e se della seggiovia tolgono il cavo e lasciano i piloni, devo 
> mappare i singoli piloni come disused:man_made=pilone_o_quelchelè, perché la 
> seggiovia in quanto la struttura non esiste più, ma i piloni sì, anche se non 
> usati (disused)

no, è questo il punto di partenza sbagliato di questo thread, cioè
volere usare un tag solo per due cose diverse: l'oggetto fisico e il
suo uso, come il "buco" di una cava o di una miniera e l'attività di
estrazione, e il pilone è sempre un pilone (aerialway=pylon) finché
non viene distrutto è la seggiovia che non esiste più, non c'è più
un'amenity, ma non è il caso iniziale che è:

> skilift ubicato nel comune di Pragelato (TO) sul terreno esiste tutto, 
> piloni, cavi, costruzioni alla partenza e all'arrivo, ma non è più 
> funzionante da qualche anno

in questo caso secondo me che vivo al mare :-D è uno skilift "chiuso"
e quindi giustamente è meglio se si vede su una mappa per sciatori, io
metterei aerialway:access=no sulla ex-partenza[1] e amenity=drag_lift
sulla way senza tag disused

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

-- 
Daniele Forsi

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

Re: [Talk-it] Uso del tag Disused e rendering

[Sergio Manzi]

Guarda qui [1 
]
 dove si dice chiaro e tondo: "disused=yes is a *bad tagging approach**, and 
won't be used to make rendering decisions* by this style".

Ciao!

[1] 
https://github.com/gravitystorm/openstreetmap-carto/issues/111#issuecomment-30161977


On 2018-11-28 20:49, Sergio Manzi wrote:
>
> P.S.: ... e se della seggiovia tolgono il cavo e lasciano i piloni, devo 
> mappare i singoli piloni come disused:man_made=/pilone_o_//quelchelè/, perché 
> la seggiovia in quanto la struttura non esiste più, ma i piloni sì, anche se 
> non usati (/disused/)
>
>
> On 2018-11-28 20:37, Sergio Manzi wrote:
>>
>> Il fatto è, mi sembra di capire, che disused=yes viene, in quanto tag 
>> deprecata, semplicemente _regalmente __ignorata_ da qualsiasi renderer, 
>> ragione per cui con "aerialway=chair_lift + disused=yes" la seggiovia viene 
>> visualizzata, _come se fosse attiva_. In un certo senso, taggando così, stai 
>> mentendo per il rendering...
>>
>> Che invece con "disused:aerialway=chair_lift" la seggiovia non appaia è, per 
>> me, semplicemente _un bug bello e buono_.
>>
>> Se un giorno toglieranno i cavi e abbatteranno i piloni della seggiovia che 
>> si fa? _Si cancella la feature dal database_, perché non esiste più, ma 
>> finché esiste ed è visibile, va visualizzata (/sulla mappa devo vedere 
>> quello che vedo coi miei occhi sul posto.../)
>>
>> Gli "disused:shop=*" hanno senso solo se per qualche motivo c'è ancora 
>> l'insegna o qualcosa del genere (/e può quindi fungere da landmark/), se il 
>> negozio non c'è più e l'insegna nemmeno, _si cancella_.
>>
>> In OSM i dati storici (/frontiera dell'Impero Romano o negozio fallito la 
>> settimana scorsa/), non ci devono proprio stare se non sono visibili sul 
>> campo.
>>
>> Ciao,
>>
>> Sergio
>>
>> On 2018-11-28 20:17, matteocalosi wrote:
>>> Ma sicuramente lo schema del lifecycle prefix è quello formalmente migliore.
>>> Però se dopo 10 anni è ancora minoritario per certi elementi della mappa un
>>> motivo ci sarà, credo soprattutto una concezione originale che lo ha creato
>>> proprio per nascondere al rendering cose come amenity=* e shop=* non più
>>> attivi senza pensare ad altri tipi di tag (a parte il caso speciale delle
>>> railway per cui si è adottata l'eccezione preesistente).
>>>
>>> Il problema sono elementi che dopo essere stati abbandonati rimangono
>>> fisicamente esistenti e non sono ben descrivibili con nuove tag: se da una
>>> parte abandoned:highway=track diventerà highway=path, oppure
>>> abandoned:building=residential diventerà building=yes, dall'altra una cava
>>> abbandonata è sempre fisicamente una cava e uno skilift in disuso lo stesso,
>>> cambia il modo in cui (non) vengono usati.
>>>
>>> Di certo non sarebbe una brutta cosa adoperarsi perchè ogni singolo motore
>>> di rendering aggiunga il supporto per entrambi i tipi di tag, ma l'uso dello
>>> schema alternativo maggioritario landuse=quarry + disused=yes e simili (vedo
>>> che esiste anche quarry=disused sullo stile delle ferrovie) non mi sembra
>>> comunque scorretto, non è ambiguo appunto perchè una cava non in attività
>>> rimane una cava, non diventa qualcos'altro.
>>>
>>> Fra l'altro per quarry la cosa è stata discussa un po' di recente
>>> https://wiki.openstreetmap.org/wiki/Talk:Tag:landuse%3Dquarry
>>>
>>>
>>>
>>>
>>> --
>>> 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


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Les voies vertes

[marc marc]

Le 27. 11. 18 à 23:25, Antoine Riche a écrit :
> j'imagine que si on demande à un humain "normal" 
> (ni expert OSM, ni aménageur, ni même cycliste) de quoi il s'agit, 
> il répondra que c'est une piste cyclable.

apparemment non :)
Je pensais que cette confusion était du passé et était LE résultat de
la discussion précédente. la voie verte n'est pas une piste cyclable
qui tolère des intrus sans vélo.

> J'aime bien l'idée que cette personne puisse mettre à jour  
> la carte et ajouter cette voie sans trop se prendre la tête

tout a fait
il voit un chemin, il tag un chemin highway=track
s'il voit plutôt une ancienne route inter-village ré-allouée
à la mobilité douce, il tag highway=unclassified

> L'aménageur qui a posé le panneau "interdit à 
> tous véhicules sauf riverains" ajoute motor_vehicle=destination. 

ok

> Enfin un cyclo-mappeur consciencieux vérifie que l'aménagement 
> est bien mappé : il voit le panneau Voie verte et ajoute traffic_sign=FR:C115.

et là je ne comprend pas.
sur quoi va se baser le cyclo-mappeur pour cet ajout ?
s'il est sur place et voit le panneau à l'entrée d'un chemin,
il peux juste constater qu'il y a un panneau et mettre un nœud.
rien ne lui permet en voyant le début du chemin de savoir si la voie 
verte persiste au prochain croisement et si à ce croisement elle 
continue avec le même chemin osm ou si le chemin osm et la voie verte 
divergent.
Si le cyclo-mappeur fait une modif depuis son salon en se basant
sur foot=designated cyclewaw=designated alors cela montre que
traffic_sign sur le way ne sert a rien puisqu'il est une information 
dérivée de tags qui sont suffisant à localiser la voie verte.
Avis perso, le contributeur "sans prise de tête" aura bien plus facile 
d'ajouter description="voie verte" plutôt que de mémoriser les codes
légaux des panneaux et deviner leur portée lorsqu'il n'emprunte pas
l'entièreté de sa longueur.

Est-ce que ton refus de la vision quasi généralisé vient-il du fait
qu'il y a une donneur d'ordre qui a un besoin de rendu particulier ?

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

Re: [Talk-it] Uso del tag Disused e rendering

[Sergio Manzi]

P.S.: ... e se della seggiovia tolgono il cavo e lasciano i piloni, devo 
mappare i singoli piloni come disused:man_made=/pilone_o_//quelchelè/, perché 
la seggiovia in quanto la struttura non esiste più, ma i piloni sì, anche se 
non usati (/disused/)


On 2018-11-28 20:37, Sergio Manzi wrote:
>
> Il fatto è, mi sembra di capire, che disused=yes viene, in quanto tag 
> deprecata, semplicemente _regalmente __ignorata_ da qualsiasi renderer, 
> ragione per cui con "aerialway=chair_lift + disused=yes" la seggiovia viene 
> visualizzata, _come se fosse attiva_. In un certo senso, taggando così, stai 
> mentendo per il rendering...
>
> Che invece con "disused:aerialway=chair_lift" la seggiovia non appaia è, per 
> me, semplicemente _un bug bello e buono_.
>
> Se un giorno toglieranno i cavi e abbatteranno i piloni della seggiovia che 
> si fa? _Si cancella la feature dal database_, perché non esiste più, ma 
> finché esiste ed è visibile, va visualizzata (/sulla mappa devo vedere quello 
> che vedo coi miei occhi sul posto.../)
>
> Gli "disused:shop=*" hanno senso solo se per qualche motivo c'è ancora 
> l'insegna o qualcosa del genere (/e può quindi fungere da landmark/), se il 
> negozio non c'è più e l'insegna nemmeno, _si cancella_.
>
> In OSM i dati storici (/frontiera dell'Impero Romano o negozio fallito la 
> settimana scorsa/), non ci devono proprio stare se non sono visibili sul 
> campo.
>
> Ciao,
>
> Sergio
>
> On 2018-11-28 20:17, matteocalosi wrote:
>> Ma sicuramente lo schema del lifecycle prefix è quello formalmente migliore.
>> Però se dopo 10 anni è ancora minoritario per certi elementi della mappa un
>> motivo ci sarà, credo soprattutto una concezione originale che lo ha creato
>> proprio per nascondere al rendering cose come amenity=* e shop=* non più
>> attivi senza pensare ad altri tipi di tag (a parte il caso speciale delle
>> railway per cui si è adottata l'eccezione preesistente).
>>
>> Il problema sono elementi che dopo essere stati abbandonati rimangono
>> fisicamente esistenti e non sono ben descrivibili con nuove tag: se da una
>> parte abandoned:highway=track diventerà highway=path, oppure
>> abandoned:building=residential diventerà building=yes, dall'altra una cava
>> abbandonata è sempre fisicamente una cava e uno skilift in disuso lo stesso,
>> cambia il modo in cui (non) vengono usati.
>>
>> Di certo non sarebbe una brutta cosa adoperarsi perchè ogni singolo motore
>> di rendering aggiunga il supporto per entrambi i tipi di tag, ma l'uso dello
>> schema alternativo maggioritario landuse=quarry + disused=yes e simili (vedo
>> che esiste anche quarry=disused sullo stile delle ferrovie) non mi sembra
>> comunque scorretto, non è ambiguo appunto perchè una cava non in attività
>> rimane una cava, non diventa qualcos'altro.
>>
>> Fra l'altro per quarry la cosa è stata discussa un po' di recente
>> https://wiki.openstreetmap.org/wiki/Talk:Tag:landuse%3Dquarry
>>
>>
>>
>>
>> --
>> 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
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Bylo: Import rozvoden v Praze / building=industrial -> building=service

[Marián Kyral]

On 28. 11. 18 20:01, Marián Kyral wrote:

On 28. 11. 18 17:57, majka wrote:

Zdravím všechny.

V rámci toho plánovaného importu se naťuknul jeden problém: většinu 
technických budov máme (díky natrasování tracerem a převodem tagů 
jako building=industrial místo building=service.


Zkusila jsem to dohledat přes overpass turbo dotazem s omezením 
velikosti, resp. délky cesty (obvodu) na 50m 
 . Jen v Českých Budějovicích a okolí 
mi to vyhazuje přes 500 budov.


Velikost byla zkoušena na mě známé trafostanici, je to kapku víc než 
považuji za jisté pro případné (polo-)automatické změny (je to např. 
budova s půdorysem 10x15m).


Pro mě to dává dvě otázky, z toho druhá je asi spíš na Mariána:

1. Nechceme vyhodit další "úkol", kde bychom se soustředili na tyhle 
budovy a opravu jejich značení?


2. Nešel by upravit Tracer, aby při trasování podle RUIAN kontroloval 
i velikost budovy, a u těch "podezřelých" buďto rovnou měnil značky 
na building=service (zejména u těch malých - malé trafostanice, 
budovy ČOV a podobně) nebo vyhodil dialog, kde by dotyčný musel sám 
rozhodnout? Klidně bych to nechala tím obvodem, pokud je to jednodušší.




Ahoj,
můžeš hodit do placu pár příkladů, abych mrknul přímo do dat? 
Kontrolovat obvod určitě půjde, jen si nejsem jist, zda to nepřinese 
více škody než užitku.


Pardon, než jsem došel sem, tak jsem zapomněl, že jsi výš dala odkaz na 
overpass turbo :-D Zkusil jsem projet okolí a asi na tom něco bude. Ale 
nic neslibuji. Teď jsem se pustil do schránek v okrese Opava ;-)


Marián


Pokud to půjde, obdobně by stálo za to zasáhnout u building=civic, 
protože v tom máme většinu kapliček, zvoniček a podobně, pokud jsou v 
RUIAN vedené jako budova, případně u building obecně, u různých 
"neobyvatelných budov" (chyby zakreslení budovy v RUIAN, takové ty 
fragmenty).




A co s těmi fragmenty pak mám dělat?

Marián


Majka

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



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


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

Re: [Talk-it] Uso del tag Disused e rendering

[Sergio Manzi]

Il fatto è, mi sembra di capire, che disused=yes viene, in quanto tag 
deprecata, semplicemente _regalmente __ignorata_ da qualsiasi renderer, ragione 
per cui con "aerialway=chair_lift + disused=yes" la seggiovia viene 
visualizzata, _come se fosse attiva_. In un certo senso, taggando così, stai 
mentendo per il rendering...

Che invece con "disused:aerialway=chair_lift" la seggiovia non appaia è, per 
me, semplicemente _un bug bello e buono_.

Se un giorno toglieranno i cavi e abbatteranno i piloni della seggiovia che si 
fa? _Si cancella la feature dal database_, perché non esiste più, ma finché 
esiste ed è visibile, va visualizzata (/sulla mappa devo vedere quello che vedo 
coi miei occhi sul posto.../)

Gli "disused:shop=*" hanno senso solo se per qualche motivo c'è ancora 
l'insegna o qualcosa del genere (/e può quindi fungere da landmark/), se il 
negozio non c'è più e l'insegna nemmeno, _si cancella_.

In OSM i dati storici (/frontiera dell'Impero Romano o negozio fallito la 
settimana scorsa/), non ci devono proprio stare se non sono visibili sul campo.

Ciao,

Sergio

On 2018-11-28 20:17, matteocalosi wrote:
> Ma sicuramente lo schema del lifecycle prefix è quello formalmente migliore.
> Però se dopo 10 anni è ancora minoritario per certi elementi della mappa un
> motivo ci sarà, credo soprattutto una concezione originale che lo ha creato
> proprio per nascondere al rendering cose come amenity=* e shop=* non più
> attivi senza pensare ad altri tipi di tag (a parte il caso speciale delle
> railway per cui si è adottata l'eccezione preesistente).
>
> Il problema sono elementi che dopo essere stati abbandonati rimangono
> fisicamente esistenti e non sono ben descrivibili con nuove tag: se da una
> parte abandoned:highway=track diventerà highway=path, oppure
> abandoned:building=residential diventerà building=yes, dall'altra una cava
> abbandonata è sempre fisicamente una cava e uno skilift in disuso lo stesso,
> cambia il modo in cui (non) vengono usati.
>
> Di certo non sarebbe una brutta cosa adoperarsi perchè ogni singolo motore
> di rendering aggiunga il supporto per entrambi i tipi di tag, ma l'uso dello
> schema alternativo maggioritario landuse=quarry + disused=yes e simili (vedo
> che esiste anche quarry=disused sullo stile delle ferrovie) non mi sembra
> comunque scorretto, non è ambiguo appunto perchè una cava non in attività
> rimane una cava, non diventa qualcos'altro.
>
> Fra l'altro per quarry la cosa è stata discussa un po' di recente
> https://wiki.openstreetmap.org/wiki/Talk:Tag:landuse%3Dquarry
>
>
>
>
> --
> 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
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Uso del tag Disused e rendering

[matteocalosi]

Interessante questa discussione di OSM-Carto
https://github.com/gravitystorm/openstreetmap-carto/issues/2124 dove si dice
specificamente che "any proposal to render an abandoned feature has a high
bar to clear", direi che conferma la mia impressione che i lifecycle prefix
siano de facto usati come elemento per descrivere una tag di cui NON fare il
rendering



--
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] Uso del tag Disused e rendering

[matteocalosi]

Ma sicuramente lo schema del lifecycle prefix è quello formalmente migliore.
Però se dopo 10 anni è ancora minoritario per certi elementi della mappa un
motivo ci sarà, credo soprattutto una concezione originale che lo ha creato
proprio per nascondere al rendering cose come amenity=* e shop=* non più
attivi senza pensare ad altri tipi di tag (a parte il caso speciale delle
railway per cui si è adottata l'eccezione preesistente).

Il problema sono elementi che dopo essere stati abbandonati rimangono
fisicamente esistenti e non sono ben descrivibili con nuove tag: se da una
parte abandoned:highway=track diventerà highway=path, oppure
abandoned:building=residential diventerà building=yes, dall'altra una cava
abbandonata è sempre fisicamente una cava e uno skilift in disuso lo stesso,
cambia il modo in cui (non) vengono usati.

Di certo non sarebbe una brutta cosa adoperarsi perchè ogni singolo motore
di rendering aggiunga il supporto per entrambi i tipi di tag, ma l'uso dello
schema alternativo maggioritario landuse=quarry + disused=yes e simili (vedo
che esiste anche quarry=disused sullo stile delle ferrovie) non mi sembra
comunque scorretto, non è ambiguo appunto perchè una cava non in attività
rimane una cava, non diventa qualcos'altro.

Fra l'altro per quarry la cosa è stata discussa un po' di recente
https://wiki.openstreetmap.org/wiki/Talk:Tag:landuse%3Dquarry




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

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

Re: [OSM-talk-fr] made_man=street_cabinet et point de livraison final d'électricité

[François Lacombe]

Hello

Est-ce que tu aurais une photo de la situation s'il te plait ?
Je comprends qu'il y a une ligne aérienne dans l'affaire. Mais une ligne
aérienne est difficilement raccordable à une armoire de rue directement, il
doit y avoir un poteau, avec un passage en souterrain entre les deux.
Sinon l'analyse osmose sera mise à jour normalement

François

Le mer. 28 nov. 2018 à 19:56, David Crochet  a
écrit :

> Bonjour
>
> Dans ce cas osmose n'est pas content, il me dit à chaque fois que la
> ligne électrique n'est pas terminé or, je peut pas faire plus et le
> coffret et bien le point final.
>
> Que veut osmose alors ?
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-ca] Canvec Import

[Viajero Perdido]

From: James 

not sure why Canvec always gets shat uppon, their water features are great
and pretty accurate


Bovine excrement.  Do I need to make an exhaustive list of the 
water-feature nonsense I keep finding?  Lakes dry up, and rivers change 
course (especially around Calgary in 2013).  Somebody imported a whole 
swath of ponds and lakes in NE Alberta, where a glance at imagery shows 
few if any still exist; it's all farmland now.


CanVec gets shat upon because the data quality is shite.  You can put 
water features in the BAD column along with landcover, POIs (schools are 
not prisons), trails (approximate is not good enough), and so on.


I am part of the CanVec immune system, because I want to see us create a 
*quality* map.


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

Re: [Talk-it] Uso del tag Disused e rendering

[Sergio Manzi]

Aggiungo un altro link al wiki [1 
],
 dal quale si evince (/mi sembra chiaramente.../) che l'uso di "disused=yes" è 
da considerarsi... disused!  :-)

[1] 
https://wiki.openstreetmap.org/wiki/Key:disused:#Former_use_.28as_a_simple_tag.29


On 2018-11-28 18:59, Sergio Manzi wrote:
>
> Lettura interessante: Comparison of life cycle concepts 
> 
>
> Notate che a un certo punto, a proposito dell'uso della sintassi " = 
> yes" (/es. disused=yes/), si dice: "/It should be considered that this would 
> be most likely be rejected if ever voted because of same concerns as 
> life_cycle=status./" cioè "Va considerato che, qualora si fosse andati al 
> voto, questa (forma) sarebbe stata molto probabilmente rifiutata per gli 
> stessi motivi per cui (è stata rifiutata la forma) /life_cycle=status"./
>
> Un'altra, lettura interessante (e piuttosto infuocata...) è  Render 
> disused:railway=rail like railway=disused 
>   specifica 
> per le railway (ma perché???).
>
> Ciao, Sergio
>
>
> On 2018-11-28 18:30, Damjan Gerl wrote:
>> deltredicialessan...@libero.it je 28.11.2018 ob 18:24 napisal:
>>>
>>> Secondo me no, è meglio il prefisso disused: altrimenti il tagging risulta 
>>> ambiguo. Landuse=quarry dice che è una cava, disused=yes che non lo è più. 
>>> L'esempio della cava forse non è il migliore (da chiusa ha lo stesso 
>>> aspetto che aveva prima alla fine) ma il principio è valido, se pensiamo ad 
>>> esempio ad uno shop=* o amenity=* si capisce meglio.
>>>
>>
>> +1 Come sempre non mappiamo per il render: qui direi che è un problema di 
>> render / o meglio non-render ;-)
>>
>> Damjan
>>
>>> Ciao
>>> Alecs
>>>
>>> mercoledì, 28 novembre 2018, 02:55PM +01:00 da Massimo Taronna 
>>> massimo.taro...@gmail.com :
>>>
>>>     Io concordo con quanto scritto da Matteo, credo sarebbe più
>>>     corretto usare i tag abandoned=yes o disused=yes per tutto ciò che
>>>     è fisicamente esistente sul territorio.
>>>
>>>     Ciao
>>>
>>>     Massimo
>>>
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Bylo: Import rozvoden v Praze / building=industrial -> building=service

[Marián Kyral]

On 28. 11. 18 17:57, majka wrote:

Zdravím všechny.

V rámci toho plánovaného importu se naťuknul jeden problém: většinu 
technických budov máme (díky natrasování tracerem a převodem tagů jako 
building=industrial místo building=service.


Zkusila jsem to dohledat přes overpass turbo dotazem s omezením 
velikosti, resp. délky cesty (obvodu) na 50m 
 . Jen v Českých Budějovicích a okolí 
mi to vyhazuje přes 500 budov.


Velikost byla zkoušena na mě známé trafostanici, je to kapku víc než 
považuji za jisté pro případné (polo-)automatické změny (je to např. 
budova s půdorysem 10x15m).


Pro mě to dává dvě otázky, z toho druhá je asi spíš na Mariána:

1. Nechceme vyhodit další "úkol", kde bychom se soustředili na tyhle 
budovy a opravu jejich značení?


2. Nešel by upravit Tracer, aby při trasování podle RUIAN kontroloval 
i velikost budovy, a u těch "podezřelých" buďto rovnou měnil značky na 
building=service (zejména u těch malých - malé trafostanice, budovy 
ČOV a podobně) nebo vyhodil dialog, kde by dotyčný musel sám 
rozhodnout? Klidně bych to nechala tím obvodem, pokud je to jednodušší.




Ahoj,
můžeš hodit do placu pár příkladů, abych mrknul přímo do dat? 
Kontrolovat obvod určitě půjde, jen si nejsem jist, zda to nepřinese 
více škody než užitku.


Pokud to půjde, obdobně by stálo za to zasáhnout u building=civic, 
protože v tom máme většinu kapliček, zvoniček a podobně, pokud jsou v 
RUIAN vedené jako budova, případně u building obecně, u různých 
"neobyvatelných budov" (chyby zakreslení budovy v RUIAN, takové ty 
fragmenty).




A co s těmi fragmenty pak mám dělat?

Marián


Majka

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


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

Re: [OSM-talk-fr] made_man=street_cabinet et point de livraison final d'électricité

[David Crochet]

Bonjour

Dans ce cas osmose n'est pas content, il me dit à chaque fois que la 
ligne électrique n'est pas terminé or, je peut pas faire plus et le 
coffret et bien le point final.


Que veut osmose alors ?

Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] bancs de sable dans fleuves et rivières [était] grèves Loire

[ades]

Je m’essayerai à une synthèse demain dans la matinée, ça devient un peu confus, 
mais je ferai un effort…  ;-) 

si quelqu’un le fait avant, je ne me vexerais pas ;-)

> Le 28 nov. 2018 à 14:50, Jérôme Seigneuret  a 
> écrit :
> 
> oui pour le wetland mais pas pour des banc de sable. Wetland ce sont des 
> zones humides donc avec une possibilité d'assèchement temporaire mais qui 
> ducoup correspond à un couvert végétal plus ou moins dense en fonction du 
> type de végétation et non a un banc de sable. On ne peut donc pas considérer 
> ça comme un wetland surtout si c'est une grève. Si la grève est stabilisé 
> avec un développement végétatif je veux bien.
> Dans le cas du wetland tidal c'est plus compliqué d'avoir un développement 
> végétatif car les marée et le mouvement d'eau empêche l'implantation. Le wiki 
> mentionne la limite cotière car c'est en lien avec la zone de mouvement 
> perpétuelle. La situation est ainsi. Un coup c'est sous l'eau un coup non.  
> C'est la définition de mudflat 
> 
> Les cours d'eau large avec des crues c'est chiant à représenter car si tu 
> veux faire joli tu vas ajouter des choses une année qui n'y seront plus là 
> l'années d'après suite à une crue ou à un curage. C'est le problème de faire 
> du micromapping sur des éléments en mouvement constant.
> Dans ce cas en effet riverbed c'est loin d'être con car c'est plus du 
> landcover et de la notion de surface. Ducoup mettre l'année c'est important
> 
> Dans les bords de mer il y a la notion de grey_dune mais c'est pour du 
> natural=grassland + grassland =grey_dune.
> 
> Bonne journée
> 
> Le mer. 28 nov. 2018 à 13:38, François Boucault  > a écrit :
> Précision concernant natural=riverbed : le fait d'ajouter aux bancs de sable 
> une relation "en tant que inner" au polygone "La Loire" réduit de fait 
> l'emprise des rives, et crée une facilement une différence entre le cours 
> d'eau et son lit saisonnier. Taguer avec riverbed est sans doute plus simple 
> que ce que j'écrivais dans mon dernier mail.
> Et sinon en lisant cette réponse à l'issue github 
> , 
> je me dis natural =wetland 
> , complété par 
> wetland =tidalflat 
>  ou wetland 
> =marsh 
> n'est peut-être pas 
> une si mauvaise solution. De plus, l'introduction de la page natural 
> =wetland 
>  fait bien 
> référence à des zones humides situées notamment le long de cours d'eau.
> 
> Désolé pour mon indécision, je suis tout embrouillé :-S
> Le 28/11/2018 à 10:04, François Boucault a écrit :
>> @Jérôme Ok pour la clef wikidata...
>> 
>> À propos des tags, voici un résumé des clés principales possibles :
>> 
>> - natural=shoal  / 
>> mais le wiki est très peu documenté, il n'y a aucune discussion, et il n'est 
>> pas fait mention des bancs de rivière, seulement de mer. j'ai tout de même 
>> trouvé ici  un exemple en 
>> rivière.
>> - natural=riverbed 
>>  / concerne 
>> plutôt l'entièreté du lit d'une rivière (dépassant du cours "minimum"). Pour 
>> l'utiliser au mieux, il faudrait réduire   l'emprise des berges 
>> (riverbanks), et remplir le vide laissé par une zone "riverbed" 
>> (correspondant aux bancs de sable). Ça me semble un peu compliqué mais ça 
>> peut faire sens.
>> 
>> - natural=wetland 
>>  / 
>> théoriquement juste, mais sans doute pas assez spécifique
>> 
>> L'avantage de Shoal, c'est qu'il est plus simple à mettre en œuvre que 
>> riverbed, et qu'il correspond bien à la terminologie utilisée localement 
>> ("Banc" de sable de Loire). Je vote pour :-)
>> 
>> @Ades natural=shoal peut être complété par différents tags, par exemple ici 
>> .
>> 
>> 
>> Le 28/11/2018 à 09:44, ades a écrit :
>>> Si j’ai bien suivi, le plus simple serait de : 
>>> délimiter une surface.
>>> la tagguer : 
>>> natural = shoal
>>> seasonal=yes (summer,autumn dans ce cas)
>>> 
>>> Avec les remarques suivantes : 
>>> 
>>> Parce que la géométrie des bancs de sable varie  chaque saison, mais que 
>>> leur emplacement est grosso modo stable, je proposerai bien que le dessin 
>>> de la surface soit limité à la zone la plus près de la rive (ou au centre 
>>> dans le cas de bancs isolé au milieu du riverbank). 
>>> 
>>> Autrement 

Re: [Talk-hr] 2018-11/12 meetup?

[tweety Ksenija]

Hej,

Matiji i meni odgovara bilo koji ponedjeljak ili petak nakon 18h

Ksenija

četvrtak, 22. studenoga 2018. korisnik hbogner 
napisao je:

> Ima li zainteresiranih za meetup prije blagdana?
>
>
> ___
> Talk-hr mailing list
> Talk-hr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-hr
>
___
Talk-hr mailing list
Talk-hr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-hr

Re: [Talk-ca] Multiple university departments in one building

[James]

tim if you need an example of how to tag multiple levels via the indoor
tagging:

I did it at St-Laurent shopping mall:

https://openlevelup.net/?l=0#18/45.42184/-75.63833

everything is tagged using the simple indoor tagging schema. I highly
suggest using JOSM filter on level=

but then again josm now has a built in filter for levels

On Wed., Nov. 28, 2018, 12:41 p.m. Tim Elrick  Thank you, John and James.
>
> Place d'Orleans looks nice. And, of course, we do not map for the
> renderer. However, as the departments that I want to map are on
> different floor levels and not specifically in this or that corner of
> the building, the approach I have taken is still not pleasing.
>
> I guess, I will read into the Simple Indoor Tagging schema then and see
> how it works out.
>
> Cheers,
> Tim
>
> On 2018-11-28 07:37, john whelan wrote:
> Have a look at OSMand and see what it looks like.
>
> Generally it is considered bad practise to map for the renderer.
>
> As an alternative take a look at Place d'Orleans shopping center in
> Orleans Ontario each unit is mapped in outline with the appropriate tags
> added.
>
> If you look at mapping a building with floors I've seen office outlines
> before now.
>
> Cheerio John
>
> On Tue, 27 Nov 2018, 8:00 pm Tim Elrick   wrote:
>
>  Hello,
>
>  I am trying to contribute to filling the gaps on McGill campus on
>  OSM at
>  the moment and I ran into a problem which I haven't fund a
> satisfactory
>  answer for yet.
>
>  We have several buildings on campus which are home to multiple
>  departments, all buildings have a building name.
>
>  I looked the OSM wiki feature pages and in the OSM forum and found the
>  following approach as apparently standard procedure:
>  1) Map building outline with building = university , name= XYZ
>  building,
>  operator=McGill University
>  2) Add a node inside the building for each department with
>  office=university, description=department name
>  This produces irritating blue dots in the outline of the building, see
>  https://osm.org/go/cIrNt~j2u 
>
>  When I looked at other universities, I found e.g. a node with
>  amenity=university, name=department name. But when looking at the OSM
>  wiki feature page for universities[1] it says you only should use
>  amenity=university for the whole campus.
>
>  The office tag I found when looking for multiple businesses in one
>  building, but the blue dot aren't nice.
>
>  Any suggestions on how to map this elegantly?
>
>  Thank you,
>  Tim (aka AGeographer)
>
>  [1] https://wiki.openstreetmap.org/wiki/Tag:amenity=university
>
>  ___
>  Talk-ca mailing list
>  Talk-ca@openstreetmap.org 
>  https://lists.openstreetmap.org/listinfo/talk-ca
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] Un nouveau 'concurrent' ?

[Cédric Frayssinet]

En effet, cela avance :)

Il y a ce pouet de Noémie ici :
https://fr.osm.social/@nlehuby/101115990378833954


Le 28/11/2018 à 15:36, Sylvain M a écrit :
> Je déterre ce sujet, car j'ai découvert "Qwant Maps" hier en live !
> Même s'il y a encore plein de fonctionnalités manquantes, je suis content de
> voir que le projet prend forme
> (comme je ne suis pas assidu sur la liste Talk-fr, peut-être cela a-t-il
> déjà été annoncé ici ?)
>
> En tout cas, voici un accès direct avec une recherche sur ma commune :
> https://www.qwant.com/local/?q=Saint-Pierre-des-Nids
>   
>
> Je suppose qu'il faudra être patient pour la suite, et je suivrai donc
> personnellement cela avec intérêt (à défaut de pouvoir contribuer)
>
> Bravo ! :)
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 
Dégooglisé !  - Sociétaire Enercoop
, l'énergie militante

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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

Re: [Talk-it] Uso del tag Disused e rendering

[Sergio Manzi]

Lettura interessante: Comparison of life cycle concepts 


Notate che a un certo punto, a proposito dell'uso della sintassi " = 
yes" (/es. disused=yes/), si dice: "/It should be considered that this would be 
most likely be rejected if ever voted because of same concerns as 
life_cycle=status./" cioè "Va considerato che, qualora si fosse andati al voto, 
questa (forma) sarebbe stata molto probabilmente rifiutata per gli stessi 
motivi per cui (è stata rifiutata la forma) /life_cycle=status"./

Un'altra, lettura interessante (e piuttosto infuocata...) è  Render 
disused:railway=rail like railway=disused 
  specifica 
per le railway (ma perché???).

Ciao, Sergio


On 2018-11-28 18:30, Damjan Gerl wrote:
> deltredicialessan...@libero.it je 28.11.2018 ob 18:24 napisal:
>>
>> Secondo me no, è meglio il prefisso disused: altrimenti il tagging risulta 
>> ambiguo. Landuse=quarry dice che è una cava, disused=yes che non lo è più. 
>> L'esempio della cava forse non è il migliore (da chiusa ha lo stesso aspetto 
>> che aveva prima alla fine) ma il principio è valido, se pensiamo ad esempio 
>> ad uno shop=* o amenity=* si capisce meglio.
>>
>
> +1 Come sempre non mappiamo per il render: qui direi che è un problema di 
> render / o meglio non-render ;-)
>
> Damjan
>
>> Ciao
>> Alecs
>>
>> mercoledì, 28 novembre 2018, 02:55PM +01:00 da Massimo Taronna 
>> massimo.taro...@gmail.com :
>>
>>     Io concordo con quanto scritto da Matteo, credo sarebbe più
>>     corretto usare i tag abandoned=yes o disused=yes per tutto ciò che
>>     è fisicamente esistente sul territorio.
>>
>>     Ciao
>>
>>     Massimo
>>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-ca] Multiple university departments in one building

[Tim Elrick]

Thank you, John and James.

Place d'Orleans looks nice. And, of course, we do not map for the 
renderer. However, as the departments that I want to map are on 
different floor levels and not specifically in this or that corner of 
the building, the approach I have taken is still not pleasing.


I guess, I will read into the Simple Indoor Tagging schema then and see 
how it works out.


Cheers,
Tim

On 2018-11-28 07:37, john whelan wrote:
Have a look at OSMand and see what it looks like.

Generally it is considered bad practise to map for the renderer.

As an alternative take a look at Place d'Orleans shopping center in
Orleans Ontario each unit is mapped in outline with the appropriate tags
added.

If you look at mapping a building with floors I've seen office outlines
before now.

Cheerio John

On Tue, 27 Nov 2018, 8:00 pm Tim Elrick mailto:o...@elrick.de> wrote:

Hello,

I am trying to contribute to filling the gaps on McGill campus on
OSM at
the moment and I ran into a problem which I haven't fund a satisfactory
answer for yet.

We have several buildings on campus which are home to multiple
departments, all buildings have a building name.

I looked the OSM wiki feature pages and in the OSM forum and found the
following approach as apparently standard procedure:
1) Map building outline with building = university , name= XYZ
building,
operator=McGill University
2) Add a node inside the building for each department with
office=university, description=department name
This produces irritating blue dots in the outline of the building, see
https://osm.org/go/cIrNt~j2u 

When I looked at other universities, I found e.g. a node with
amenity=university, name=department name. But when looking at the OSM
wiki feature page for universities[1] it says you only should use
amenity=university for the whole campus.

The office tag I found when looking for multiple businesses in one
building, but the blue dot aren't nice.

Any suggestions on how to map this elegantly?

Thank you,
Tim (aka AGeographer)

[1] https://wiki.openstreetmap.org/wiki/Tag:amenity=university

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


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

Re: [OSM-talk-fr] Places PMR ?

[gnrc]

Sur Lyon les 1300 places ont aussi été saisies à partir de 
l'Opendata-GrandLyon. 

Christian (gnrc69) 

- Mail original -

De: "Christian Quest"  
À: talk-fr@openstreetmap.org 
Envoyé: Mercredi 28 Novembre 2018 14:42:47 
Objet: Re: [OSM-talk-fr] Places PMR ? 

Bonjour Hélène, 

Voici une requête overpass qui permet de facilement visualiser ces places: 

https://overpass-turbo.eu/s/E5t 

On voit via overpass que sur Paris, une partie des arrondissements a été 
importée, mais pas tous: https://overpass-turbo.eu/s/E5v 

Elle prend en compte: 

- amenity=parking_space + wheelchair=yes/only 

- amenity=parking/parking_space + capacity:disabled=1..9 


Sur le rendu FR ces tags sont en principe rendus, mais bien sûr le 
placement d'objets faits que l'icône peut être masquée par autre chose 
et elle n'est pas forcément non plus très mise en avant... 

Exemple: 
https://tile.openstreetmap.fr/?zoom=20=48.80492=2.48482=B00FF
 



Le 28/11/2018 à 11:23, Hélène PETIT a écrit : 
> Bonjour à tous ! 
> Je suis désormais confrontée à la nécessité de localiser une place pmr 
> avant d'entreprendre de me déplacer en voiture. 
> 
> J'ai relu un certain nombre de pages du wiki, mais la question du 
> rendu est peu abordée. 
> 
> Quels sont les fonds de carte qui font apparaître ces données : 
> https://www.data.gouv.fr/fr/reuses/integration-des-donnees-dans-openstreetmap-et-visualisation-stationnement-pmr/
>  
> 
> 
> Merci ! 
> 
> 
> Le 18/03/2018 à 19:39, PanierAvide a écrit : 
>> Bonjour, 
>> 
>> En lisant le wiki, je me rends compte que pour décrire les places de 
>> parking individuelles (amenity=parking_space), on est pas sensé 
>> pouvoir utiliser les variantes de capacity:*=* [1], mais plutôt 
>> restreindre avec des critères d'accessibilité plus classiques. 
>> 
>> En ce qui concerne les places PMR, j'ai pour habitude de renseigner 
>> un combo amenity=parking_space + capacity:disabled=1 + wheelchair=yes 
>> (si la place est vraiment accessible, ce qui n'est pas toujours le 
>> cas). J'ai cru comprendre qu'il y avait aussi possibilité d'utiliser 
>> parking_space=disabled. 
>> 
>> Ma question est la suivante : quelle est donc la bonne pratique sur 
>> la question des places PMR ? Car ça vaudrait le coup de s'accorder et 
>> de l'expliciter sur le wiki :-) 
>> 
>> Cordialement, 
>> 
>> Adrien. 
>> 
>> [1] https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dparking_space 
>> 
> 
> 
> ___ 
> 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 

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

Re: [Talk-it] Uso del tag Disused e rendering

[Damjan Gerl]

deltredicialessan...@libero.it je 28.11.2018 ob 18:24 napisal:


Secondo me no, è meglio il prefisso disused: altrimenti il tagging 
risulta ambiguo. Landuse=quarry dice che è una cava, disused=yes che 
non lo è più. L'esempio della cava forse non è il migliore (da chiusa 
ha lo stesso aspetto che aveva prima alla fine) ma il principio è 
valido, se pensiamo ad esempio ad uno shop=* o amenity=* si capisce 
meglio.




+1 Come sempre non mappiamo per il render: qui direi che è un problema 
di render / o meglio non-render ;-)


Damjan


Ciao
Alecs

mercoledì, 28 novembre 2018, 02:55PM +01:00 da Massimo Taronna 
massimo.taro...@gmail.com :


Io concordo con quanto scritto da Matteo, credo sarebbe più
corretto usare i tag abandoned=yes o disused=yes per tutto ciò che
è fisicamente esistente sul territorio.

Ciao

Massimo




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

Re: [Talk-it] Uso del tag Disused e rendering

[deltredicialessandro]

Secondo me no, è meglio il prefisso disused: altrimenti il tagging risulta 
ambiguo. Landuse=quarry dice che è una cava, disused=yes che non lo è più. 
L'esempio della cava forse non è il migliore (da chiusa ha lo stesso aspetto 
che aveva prima alla fine) ma il principio è valido, se pensiamo ad esempio ad 
uno shop=* o amenity=* si capisce meglio.
Ciao
Alecs mercoledì, 28 novembre 2018, 02:55PM +01:00 da Massimo Taronna  
massimo.taro...@gmail.com :

>Io concordo con quanto scritto da Matteo, credo sarebbe più corretto usare i 
>tag abandoned=yes o disused=yes per tutto ciò che è fisicamente esistente sul 
>territorio.
>
>Ciao
>
>Massimo
>___
>Talk-it mailing list
>Talk-it@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-it
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] Forest Routes

[Minh Nguyen]

On 2018-11-28 06:49, Martijn van Exel wrote:

On Wed, 28 Nov 2018 02:07:45 -0800
Minh Nguyen  wrote:


On 2018-11-28 01:57, Minh Nguyen wrote:

On 2018-11-20 08:57, Martijn van Exel wrote:

When I map these roads I include the FS number (just the number)
as a ref, since that is how they are signposted in the field.


I think the ref tag on the ways should have a prefix and not just
consist of a bare number. Otherwise, it's just as ambiguous for
data consumers as the (123) refs all over New Jersey, since the
U.S. doesn't have a highway tag that corresponds one-for-one with
forest routes.


(I hit send too soon.) Lots of shields show only the number and no
prefix, such as the U.S. Route shield, but we still use the "US"
prefix anyways.

Data consumers really should be using route relations instead of ref
tags on ways whenever possible. Some ambiguity is unavoidable on way
refs, which IMO should reflect what's on plain-text signage or in
publications. If one thinks of the way refs as a compatibility shim,
then "FS" doesn't seem unreasonable as a prefix.


I think you are right. It would be good if we can arrive at a common
prefix and document it on the wiki. 'FS' makes sense. Perhaps even a new
page dedicated to roads that are maintained directly by federal agencies
(NPS, USDA, others?) would make sense. I'd be happy to help set it up.


One page already documented an "NFH" prefix on ways and 
network=US:NFSR: on relations. [1] I think I added that entry to 
the table after seeing it on some forest routes in California. [2] But 
I've changed it to an "FS" prefix since so many more ways are tagged 
with that prefix. [3]


[1] https://wiki.openstreetmap.org/wiki/United_States_roads_tagging/Routes
[2] http://overpass-turbo.eu/s/E5V
[3] http://overpass-turbo.eu/s/E5W
--
m...@nguyen.cincinnati.oh.us



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

[Talk-cz] Bylo: Import rozvoden v Praze / building=industrial -> building=service

[majka]

Zdravím všechny.

V rámci toho plánovaného importu se naťuknul jeden problém: většinu
technických budov máme (díky natrasování tracerem a převodem tagů jako
building=industrial místo building=service.

Zkusila jsem to dohledat přes overpass turbo dotazem s omezením velikosti,
resp. délky cesty (obvodu) na 50m  . Jen v
Českých Budějovicích a okolí mi to vyhazuje přes 500 budov.

Velikost byla zkoušena na mě známé trafostanici, je to kapku víc než
považuji za jisté pro případné (polo-)automatické změny (je to např. budova
s půdorysem 10x15m).

Pro mě to dává dvě otázky, z toho druhá je asi spíš na Mariána:

1. Nechceme vyhodit další "úkol", kde bychom se soustředili na tyhle budovy
a opravu jejich značení?

2. Nešel by upravit Tracer, aby při trasování podle RUIAN kontroloval i
velikost budovy, a u těch "podezřelých" buďto rovnou měnil značky na
building=service (zejména u těch malých - malé trafostanice, budovy ČOV a
podobně) nebo vyhodil dialog, kde by dotyčný musel sám rozhodnout? Klidně
bych to nechala tím obvodem, pokud je to jednodušší.

Pokud to půjde, obdobně by stálo za to zasáhnout u building=civic, protože
v tom máme většinu kapliček, zvoniček a podobně, pokud jsou v RUIAN vedené
jako budova, případně u building obecně, u různých "neobyvatelných budov"
(chyby zakreslení budovy v RUIAN, takové ty fragmenty).

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

Re: [Talk-de] service=driveway für alles was service ist?

[Florian Lohoff]

On Wed, Nov 28, 2018 at 05:39:53PM +0100, chris66 wrote:
> Am 28.11.2018 um 08:18 schrieb Florian Lohoff:
> 
> > ich habe eine Diskussion zum Thema highway=service/service=driveway
> > angezettelt weil eine Gruppe von Mappern in Bielefeld begonnen hat
> > quasi alles was highway=service ist aber noch keinen service=* hat
> > mit einem service=driveway zu versorgen.
> > 
> 
> Das ist schlecht/falsch, da service ohne subtag höher klassifiziert ist
> als service mit service=driveway.
> 
> Sollte IMHO revertiert werden.

Ich würde mal sagen 80-90% des taggings ist schon in Ordnung. Ich habe
auf der osm-owl liste die changeset links zu osmcha geschrieben ...

Aber so ein paar sachen wie wege rund um den IKEA Bielefeld ist jetzt
auch alles driveway ...

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


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

Re: [Talk-ca] canvec imports

[Matthew Darwin]

Andrew,

Keep up the great work making OSM great for Canada.


On 2018-11-27 1:36 p.m., Andrew Lester wrote:
I agree. A selective import from CANVEC is fine and generally gives 
good results. As long as you don't import things like forests and 
buildings (which are both woefully out-of-date, broken, or outright 
wrong), there usually isn't a problem. However, if someone just 
imports an entire block of data without inspecting it, that's when 
we run into the visible issues that the peanut gallery picks apart.


Andrew
Victoria, BC

--
*From: *"James" 
*To: *"Andrew" 
*Cc: *"talk-ca" 
*Sent: *Tuesday, November 27, 2018 9:58:19 AM
*Subject: *Re: [Talk-ca] canvec imports

not sure why Canvec always gets shat uppon, their water features are 
great and pretty accurate, the forest/landcover on the other hand 
needs fixing before import. I think it's clear enough on the canvec 
wiki page that only experienced mappers/importers should attempt a 
canvec import.


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

Re: [Talk-de] service=driveway für alles was service ist?

[chris66]

Am 28.11.2018 um 08:18 schrieb Florian Lohoff:


ich habe eine Diskussion zum Thema highway=service/service=driveway
angezettelt weil eine Gruppe von Mappern in Bielefeld begonnen hat
quasi alles was highway=service ist aber noch keinen service=* hat
mit einem service=driveway zu versorgen.



Das ist schlecht/falsch, da service ohne subtag höher klassifiziert ist
als service mit service=driveway.

Sollte IMHO revertiert werden.

Cheers, Chris





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

Re: [Talk-pt] Gestor de tarefas está de volta e actualizado

[Pedro Lima]

Obrigado Marcos, vou ver isso quando chegar a casa

Cumprimentos,
Pedro Lima

Em qua, 28 de nov de 2018 às 16:10, Marcos Oliveira <
marcosoliveira.2...@gmail.com> escreveu:

> Olá Pedro,
>
>
>
> Meti-te como Project Manager, deves poder criar projetos agora.
>
>
>
> Podes usar isto para te familiarizas-te, mas é fácil de qualquer das
> formas. 
>
>
>
> https://learnosm.org/en/coordination/tasking-manager3-project-admin/
>
>
>
> *De: *Pedro Lima 
> *Enviado: *28 de novembro de 2018 16:07
> *Para: *OSM Portugal 
> *Assunto: *Re: [Talk-pt]Gestor de tarefas está de volta e actualizado
>
>
>
> Boa iniciativa, não fazia ideia.
>
> Gostava de experimentar essa ferramenta para melhorar a minha zona, e
> coordenar melhor por exemplo o Grande Porto.
>
>
>
> Cumprimentos,
>
> Pedro Lima
>
>
>
> Em ter, 27 de nov de 2018 às 13:56, Marcos Oliveira <
> marcosoliveira.2...@gmail.com> escreveu:
>
> Olá a todos,
>
>
>
> O Jorge Gustavo dedicou uma parte do seu tempo para resolver uns problemas
> com o site e aproveitou para actualizar o gestor de tarefas para a versão
> mas recente.
>
>
>
> https://tarefas.openstreetmap.pt/
>
>
>
> Para quem não sabe o gestor permite organizar o mapeamento de sítios ao
> dividir um polígono previamente desenhado em parcelas com áreas iguais, o
> que ajuda imenso para quem organiza mapping parties! Também dá
> perfeitamente para uso individual.
>
>
>
> Qualquer um pode contribuir mas a criação de tarefas é necessária uma
> autorização especial. Se tiveres interessado em criar tarefas manda uma
> mensagem a mim ou ao Jorge.
>
> --
>
> Um Abraço,
> Marcos Oliveira
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-it] Tablet con Osmand al posto del navigatore per il 118

[riccardo pastocchi]

Perfetto grazie 

> Il giorno 28 nov 2018, alle ore 14:11, antonyb  ha 
> scritto:
> 
> Ti racconto la mia esperienza: 
> da più di 4 anni uso un vecchio tablet economico Asus in modalità aereo (non
> ho dati) funziona tutto molto bene, quando sono a casa aggiorno le mappe una
> volta al mese, anche dentro roma con vie strette e palazzi vicini funziona
> molto bene. Ti rimane il problema dei numeri civici che sulle mappe
> scarseggiano, ma se man mano li aggiungi tu oltre a contribuire in osm avrai
> la perfezione.
> 
> 
> 
> --
> 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


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

Re: [Talk-gb-westmidlands] Saturday Mapping

[Brian Prangle]

H Gareth

Shame about that. I'm now not able to do the 8th Dec so I'll turn out this
Sat. There's a new pub there called the Tuning Fork. Anybody else up for
this?

Regards

Brian

On Sun, Nov 25, 2018 at 5:53 PM Gareth L  wrote:

> I’m rather local to this, but sadly I am away both weekends!
> It’s worthwhile doing. Google maps and Apple maps are lagging quite far
> behind on Rugby’s redevelopments/developments. Surprisingly, an entire
> retail park is missing from both.
>
>
> Gareth
>
>
> Get Outlook for iOS 
>
>
> From: Brian Prangle 
> To: talk-gb-westmidlands 
> Subject: [Talk-gb-westmidlands] Saturday Mapping
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> Hi everyone
>
> It's a been a while since we met in November and I agrred to to get some
> dates for a mapping dayin Warwicks(with a pub lunch). I propose either
> Saturday 1 Dec or 8 Dec and I propose we go to the new village being built
> on the old Rugby Radio Station site which is called Houlton
> 
>
> It's a massive development( over 6,000 homes - partially complete) with the
> first residents moving in a year ago and also a new primary school
> operational. Currently it's shown as a construction site with a few service
> roads. If folk can get to me reasonably quickly I'll see if I can drum up
> some local interest
>
> Regards
>
> Brian
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk-gb-westmidlands/attachments/20181122/841874d1/attachment-0001.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>
>
> --
>
> End of Talk-gb-westmidlands Digest, Vol 121, Issue 1
> 
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

Re: [Talk-pt] Gestor de tarefas está de volta e actualizado

[Marcos Oliveira]

Olá Pedro,

Meti-te como Project Manager, deves poder criar projetos agora.

Podes usar isto para te familiarizas-te, mas é fácil de qualquer das formas. 

https://learnosm.org/en/coordination/tasking-manager3-project-admin/

De: Pedro Lima
Enviado: 28 de novembro de 2018 16:07
Para: OSM Portugal
Assunto: Re: [Talk-pt]Gestor de tarefas está de volta e actualizado

Boa iniciativa, não fazia ideia.
Gostava de experimentar essa ferramenta para melhorar a minha zona, e coordenar 
melhor por exemplo o Grande Porto.

Cumprimentos,
Pedro Lima

Em ter, 27 de nov de 2018 às 13:56, Marcos Oliveira 
 escreveu:
Olá a todos,

O Jorge Gustavo dedicou uma parte do seu tempo para resolver uns problemas com 
o site e aproveitou para actualizar o gestor de tarefas para a versão mas 
recente.

https://tarefas.openstreetmap.pt/  

Para quem não sabe o gestor permite organizar o mapeamento de sítios ao dividir 
um polígono previamente desenhado em parcelas com áreas iguais, o que ajuda 
imenso para quem organiza mapping parties! Também dá perfeitamente para uso 
individual.

Qualquer um pode contribuir mas a criação de tarefas é necessária uma 
autorização especial. Se tiveres interessado em criar tarefas manda uma 
mensagem a mim ou ao Jorge.
-- 
Um Abraço,
Marcos Oliveira
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

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

Re: [Talk-pt] Gestor de tarefas está de volta e actualizado

[Pedro Lima]

Boa iniciativa, não fazia ideia.
Gostava de experimentar essa ferramenta para melhorar a minha zona, e
coordenar melhor por exemplo o Grande Porto.

Cumprimentos,
Pedro Lima

Em ter, 27 de nov de 2018 às 13:56, Marcos Oliveira <
marcosoliveira.2...@gmail.com> escreveu:

> Olá a todos,
>
> O Jorge Gustavo dedicou uma parte do seu tempo para resolver uns problemas
> com o site e aproveitou para actualizar o gestor de tarefas para a versão
> mas recente.
>
> https://tarefas.openstreetmap.pt/
>
> Para quem não sabe o gestor permite organizar o mapeamento de sítios ao
> dividir um polígono previamente desenhado em parcelas com áreas iguais, o
> que ajuda imenso para quem organiza mapping parties! Também dá
> perfeitamente para uso individual.
>
> Qualquer um pode contribuir mas a criação de tarefas é necessária uma
> autorização especial. Se tiveres interessado em criar tarefas manda uma
> mensagem a mim ou ao Jorge.
> --
> Um Abraço,
> Marcos Oliveira
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-gb-westmidlands] Sainsbury selly oak

[Brian Prangle]

Hi Andy

Good to see you still taking an interest in the West Mids.How's the new
house going?  I've updatde the tags and left a note on the old Sainsbury's.
I saw the dev plans for the Lapal canal but it's not yet accessible - stlll
a construction site

Regards

Brian

On Tue, 27 Nov 2018 at 11:36, Andy Robinson  wrote:

> As a follow-up, it would be great to update the Dudley No.2 canal work
> across the Sainsbury site. They haven't raised all the money to complete
> but
> the developers have done a load already and this way needs updating to
> reflect progress: https://www.openstreetmap.org/way/573536067
>
> For info at http://www.lapalcanal.co.uk/
>
> Cheers
> Andy
>
> -Original Message-
> From: Andy Robinson [mailto:ajrli...@gmail.com]
> Sent: 27 November 2018 11:31
> To: talk-gb-westmidlands@openstreetmap.org
> Subject: Sainsbury selly oak
>
> If anyone is in Selly Oak can they update the new Sainsbury development &
> surrounds etc. Brian, I see you were there doing just that three weeks ago.
> The new store opened last week (my daughter says she got "lost" in there on
> Saturday :-) ). I assume the old store is now shut? And is the fuel station
> open too? The new store is "experimental" and incorporates a food court,
> Oasis concession, and fully integrated Habitat and Argos. I see the Argos
> tag on a node.
>
> Cheers
> Andy
>
>
>
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

[Talk-it] surface: concrete_plates o paving_stones

[demon.box]

ciao in questo caso:


 


 

con mattonelle di medie dimensioni in cemento con una piccola distaziatura
(fuga) tra una e l'altra:

surface=concrete_plates

oppure

superface=paving_stones?

grazie

--enrico




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

[Talk-de] name:prefix / name:suffix auf admin boundaries

[Florian Lohoff]

Hi,
ich versuche gerade eine Methode zu finde wie ich aus den 
den

name
name:prefix
name:suffix

den offiziellen Namen einer Stadt/Admin boundary finde

Beispiele - offizielle Städte "Halle (Westf.)" und "Werther (Westf.)"

Halle:
name=Halle (Westf.)
name:prefix=Stadt
alt_name=Halle (Westfalen)

Werther:
name=Werther
name:prefix=Stadt
name:suffix=(Westf.)

Ich halte das für ziemlich fucked up. Wenn der offizielle name
name:prefix + " " + name + " " + name:suffix ist wäre das

Stadt Halle (Westf.)
Stadt Werther (Westf.)

Stadt ist aber nicht Namensbestandteil.

Gibts irgendwo niedergeschriebene Doku wie das zu sein hat? Was aus den
tags bildet den offiziellen namen?

Wenn man dem bischen für name:prefix/suffix im Wiki folgt ist das auf
Straßen in den USA eher um Bestandteile an den Namen zu hängen die eben
nicht zum offiziellen namen gehören aber sichtbar in der Karte sein
sollen. Also name=M44 name:prefix=North entsprechend dann die andere
Fahrbahn. Wenn man dem Konzept folgt müsste also name:prefix weg 
und name:suffix ebenfalls und in name müsste der offizielle name 
also "Werther (Westf.)" und "Halle (Westf.)"

Meinungen?

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


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

Re: [Talk-us] Forest Routes

[Martijn van Exel]

On Wed, 28 Nov 2018 02:07:45 -0800
Minh Nguyen  wrote:

> On 2018-11-28 01:57, Minh Nguyen wrote:
> > On 2018-11-20 08:57, Martijn van Exel wrote:  
> >> When I map these roads I include the FS number (just the number)
> >> as a ref, since that is how they are signposted in the field.   
> > 
> > I think the ref tag on the ways should have a prefix and not just 
> > consist of a bare number. Otherwise, it's just as ambiguous for
> > data consumers as the (123) refs all over New Jersey, since the
> > U.S. doesn't have a highway tag that corresponds one-for-one with
> > forest routes.  
> 
> (I hit send too soon.) Lots of shields show only the number and no 
> prefix, such as the U.S. Route shield, but we still use the "US"
> prefix anyways.
> 
> Data consumers really should be using route relations instead of ref 
> tags on ways whenever possible. Some ambiguity is unavoidable on way 
> refs, which IMO should reflect what's on plain-text signage or in 
> publications. If one thinks of the way refs as a compatibility shim, 
> then "FS" doesn't seem unreasonable as a prefix.

I think you are right. It would be good if we can arrive at a common
prefix and document it on the wiki. 'FS' makes sense. Perhaps even a new
page dedicated to roads that are maintained directly by federal agencies
(NPS, USDA, others?) would make sense. I'd be happy to help set it up.

Martijn

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

[Talk-cat] Adreces de Port de Barcelona

[Enric Rodellas]

Hola
Avui el Raf m'ha fet notar que hem fet alguna (o moltes) coses incorrectes
en pujar les adreces del Port de Barcelona.
No n'erem conscients i no hem estat al cas de:
https://www.openstreetmap.org/changeset/48757646

Però tampoc he matat cap elefant.
Agrairé qualsevol recomanació i ajuda.
Ens ho mirem i intentarem reparar-ho o revertir-ho.

Gràcies per l'ajuda (i comprensió i paciència amb els ignorants)
i gràcies a la comunitat openstreet. Al Port de Barcelona l'utilitzem pel
routing terrestre, que en algunes coses és millor que el Google Maps
-- 
Enric Rodellas
enricrodel...@gmail.com
___
Talk-cat mailing list
Talk-cat@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cat

Re: [OSM-talk-fr] Re: Places PMR ?

[Gwenaël Jouvin]

Ne faudrait-il pas également tenir compte de disabled ?
Par exemple, acces=no + disabled=yes


Le 28/11/2018 à 14:53, Jérôme Seigneuret a écrit :
> tu peux ajouter designated
> 
> amenity=parking_space + wheelchair=yes/only/designated
> 
> Bonne journée 
> 
> Le mer. 28 nov. 2018 à 14:43, Christian Quest  > a écrit :
> 
> Bonjour Hélène,
> 
> Voici une requête overpass qui permet de facilement visualiser ces places:
> 
> https://overpass-turbo.eu/s/E5t
> 
> On voit via overpass que sur Paris, une partie des arrondissements a été
> importée, mais pas tous: https://overpass-turbo.eu/s/E5v
> 
> Elle prend en compte:
> 
> - amenity=parking_space + wheelchair=yes/only
> 
> - amenity=parking/parking_space + capacity:disabled=1..9
> 
> 
> Sur le rendu FR ces tags sont en principe rendus, mais bien sûr le
> placement d'objets faits que l'icône peut être masquée par autre chose
> et elle n'est pas forcément non plus très mise en avant...
> 
> Exemple:
> 
> https://tile.openstreetmap.fr/?zoom=20=48.80492=2.48482=B00FF
> 
> 
> 
> Le 28/11/2018 à 11:23, Hélène PETIT a écrit :
> > Bonjour à tous !
> > Je suis désormais confrontée à la nécessité de localiser une place pmr
> > avant d'entreprendre de me déplacer en voiture.
> >
> > J'ai relu un certain nombre de pages du wiki, mais la question du
> > rendu est peu abordée.
> >
> > Quels sont les fonds de carte qui font apparaître ces données :
> > 
> https://www.data.gouv.fr/fr/reuses/integration-des-donnees-dans-openstreetmap-et-visualisation-stationnement-pmr/
> >
> >
> > Merci !
> >
> >
> > Le 18/03/2018 à 19:39, PanierAvide a écrit :
> >> Bonjour,
> >>
> >> En lisant le wiki, je me rends compte que pour décrire les places de
> >> parking individuelles (amenity=parking_space), on est pas sensé
> >> pouvoir utiliser les variantes de capacity:*=* [1], mais plutôt
> >> restreindre avec des critères d'accessibilité plus classiques.
> >>
> >> En ce qui concerne les places PMR, j'ai pour habitude de renseigner
> >> un combo amenity=parking_space + capacity:disabled=1 + wheelchair=yes
> >> (si la place est vraiment accessible, ce qui n'est pas toujours le
> >> cas). J'ai cru comprendre qu'il y avait aussi possibilité d'utiliser
> >> parking_space=disabled.
> >>
> >> Ma question est la suivante : quelle est donc la bonne pratique sur
> >> la question des places PMR ? Car ça vaudrait le coup de s'accorder et
> >> de l'expliciter sur le wiki :-)
> >>
> >> Cordialement,
> >>
> >> Adrien.
> >>
> >> [1] https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dparking_space
> >>
> >
> >
> > ___
> > 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
> 
> 
> 
> -- 
> Cordialement,
> Jérôme Seigneuret
> 
> ___
> 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] Un nouveau 'concurrent' ?

[Sylvain M]

Je déterre ce sujet, car j'ai découvert "Qwant Maps" hier en live !
Même s'il y a encore plein de fonctionnalités manquantes, je suis content de
voir que le projet prend forme
(comme je ne suis pas assidu sur la liste Talk-fr, peut-être cela a-t-il
déjà été annoncé ici ?)

En tout cas, voici un accès direct avec une recherche sur ma commune :
https://www.qwant.com/local/?q=Saint-Pierre-des-Nids
  

Je suppose qu'il faudra être patient pour la suite, et je suivrai donc
personnellement cela avec intérêt (à défaut de pouvoir contribuer)

Bravo ! :)



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-de] Boundary Kreise und Kreisfreie Städte

[wambacher]

Erwischt! ja, hab das leider vertauscht. War ein wenig hektisch gestern.
Aber dennoch ist das der mMn einfachste und schnellste Weg.

Gruss

walter

Am 28.11.18 um 13:49 schrieb Rolf Eike Beer:
> Am 2018-11-27 21:20, schrieb wambac...@posteo.de:
>> Hi, das ist ganz einfach: Der Amtliche Gemeindeschlüssel von Kreisen und
>> Kreisfreien Städten ist unterschiedlich lang.
>>
>> Der AGS von Kreisen hat die Länge 8 und der von Kreisfreien Städten ist
>> exakt 5 Zeichen lang. Das gilt für ganz Deutschland.
>
> Nach deiner Tabelle ist es genau andersherum.
>
>>  name  | admin_level |
>> de:amtlicher_gemeindeschluessel
>> ---+-+-
>>
>>  Halle (Saale) | 6   | 15002000
>>  Munich    | 6   | 09162000
>>  Kreis Groß-Gerau  | 6   | 06433
>>  Kreis Euskirchen  | 6   | 05366
>>  Landkreis Peine   | 6   | 03157
>>  Landkreis Neustadt an der Aisch-Bad Windsheim | 6   | 09575
>>  Landkreis Neunkirchen | 6   | 10043
>>  Landkreis Neumarkt in der Oberpfalz   | 6   | 09373
>>  Landkreis München | 6   | 09184
>>  Landkreis Mühldorf am Inn | 6   | 09183
>>  Landkreis Miesbach    | 6   | 09182
>>  Landkreis Neu-Ulm | 6   | 09775
>>  Landkreis Neustadt an der Waldnaab    | 6   | 09374
>>  Passau    | 6   | 09262000
>>  Landkreis Eichsfeld   | 6   | 16061
>>  Landkreis Ebersberg   | 6   | 09175
>>  Landkreis Dingolfing-Landau   | 6   | 09279
>>  Landkreis Dillingen an der Donau  | 6   | 09773
>>  Landkreis Diepholz    | 6   | 03251
>>  Landkreis Deggendorf  | 6   | 09271
>> (20 Zeilen)
>
> Eike
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
-- 
My projects:

Admin Boundaries of the World 
Missing Boundaries

Emergency Map 
Postal Code Map (Germany only) 
Fools (QA for zipcodes in Germany) 
Postcode Boundaries of Germany 
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-it] Uso del tag Disused e rendering

[Sergio Manzi]

OK, ma per quale ragione?

On 2018-11-28 14:55, Massimo Taronna wrote:
> Io concordo con quanto scritto da Matteo, credo sarebbe più corretto usare i 
> tag abandoned=yes o disused=yes per tutto ciò che è fisicamente esistente sul 
> territorio.
>
> Ciao
>
> Massimo
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Uso del tag Disused e rendering

[Massimo Taronna]

Io concordo con quanto scritto da Matteo, credo sarebbe più corretto usare
i tag abandoned=yes o disused=yes per tutto ciò che è fisicamente esistente
sul territorio.

Ciao

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

Re: [OSM-talk-fr] Places PMR ?

[Jérôme Seigneuret]

tu peux ajouter designated

amenity=parking_space + wheelchair=yes/only/designated

Bonne journée

Le mer. 28 nov. 2018 à 14:43, Christian Quest  a
écrit :

> Bonjour Hélène,
>
> Voici une requête overpass qui permet de facilement visualiser ces places:
>
> https://overpass-turbo.eu/s/E5t
>
> On voit via overpass que sur Paris, une partie des arrondissements a été
> importée, mais pas tous: https://overpass-turbo.eu/s/E5v
>
> Elle prend en compte:
>
> - amenity=parking_space + wheelchair=yes/only
>
> - amenity=parking/parking_space + capacity:disabled=1..9
>
>
> Sur le rendu FR ces tags sont en principe rendus, mais bien sûr le
> placement d'objets faits que l'icône peut être masquée par autre chose
> et elle n'est pas forcément non plus très mise en avant...
>
> Exemple:
>
> https://tile.openstreetmap.fr/?zoom=20=48.80492=2.48482=B00FF
>
>
>
> Le 28/11/2018 à 11:23, Hélène PETIT a écrit :
> > Bonjour à tous !
> > Je suis désormais confrontée à la nécessité de localiser une place pmr
> > avant d'entreprendre de me déplacer en voiture.
> >
> > J'ai relu un certain nombre de pages du wiki, mais la question du
> > rendu est peu abordée.
> >
> > Quels sont les fonds de carte qui font apparaître ces données :
> >
> https://www.data.gouv.fr/fr/reuses/integration-des-donnees-dans-openstreetmap-et-visualisation-stationnement-pmr/
> >
> >
> > Merci !
> >
> >
> > Le 18/03/2018 à 19:39, PanierAvide a écrit :
> >> Bonjour,
> >>
> >> En lisant le wiki, je me rends compte que pour décrire les places de
> >> parking individuelles (amenity=parking_space), on est pas sensé
> >> pouvoir utiliser les variantes de capacity:*=* [1], mais plutôt
> >> restreindre avec des critères d'accessibilité plus classiques.
> >>
> >> En ce qui concerne les places PMR, j'ai pour habitude de renseigner
> >> un combo amenity=parking_space + capacity:disabled=1 + wheelchair=yes
> >> (si la place est vraiment accessible, ce qui n'est pas toujours le
> >> cas). J'ai cru comprendre qu'il y avait aussi possibilité d'utiliser
> >> parking_space=disabled.
> >>
> >> Ma question est la suivante : quelle est donc la bonne pratique sur
> >> la question des places PMR ? Car ça vaudrait le coup de s'accorder et
> >> de l'expliciter sur le wiki :-)
> >>
> >> Cordialement,
> >>
> >> Adrien.
> >>
> >> [1] https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dparking_space
> >>
> >
> >
> > ___
> > 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
>


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

Re: [OSM-talk-fr] bancs de sable dans fleuves et rivières [était] grèves Loire

[Jérôme Seigneuret]

oui pour le wetland mais pas pour des banc de sable. Wetland ce sont des
zones humides donc avec une possibilité d'assèchement temporaire mais qui
ducoup correspond à un couvert végétal plus ou moins dense en fonction du
type de végétation et non a un banc de sable. On ne peut donc pas
considérer ça comme un wetland surtout si c'est une grève. Si la grève est
stabilisé avec un développement végétatif je veux bien.
Dans le cas du wetland tidal c'est plus compliqué d'avoir un développement
végétatif car les marée et le mouvement d'eau empêche l'implantation. Le
wiki mentionne la limite cotière car c'est en lien avec la zone de
mouvement perpétuelle. La situation est ainsi. Un coup c'est sous l'eau un
coup non.  C'est la définition de mudflat


Les cours d'eau large avec des crues c'est chiant à représenter car si tu
veux faire joli tu vas ajouter des choses une année qui n'y seront plus là
l'années d'après suite à une crue ou à un curage. C'est le problème de
faire du micromapping sur des éléments en mouvement constant.
Dans ce cas en effet riverbed c'est loin d'être con car c'est plus du
landcover et de la notion de surface. Ducoup mettre l'année c'est important

Dans les bords de mer il y a la notion de grey_dune mais c'est pour du
natural=grassland + grassland =grey_dune.

Bonne journée

Le mer. 28 nov. 2018 à 13:38, François Boucault  a
écrit :

> Précision concernant natural=riverbed : le fait d'ajouter aux bancs de
> sable une relation "en tant que inner" au polygone "La Loire" réduit de
> fait l'emprise des rives, et crée une facilement une différence entre le
> cours d'eau et son lit saisonnier. Taguer avec riverbed est sans doute plus
> simple que ce que j'écrivais dans mon dernier mail.
>
> Et sinon en lisant cette réponse à l'issue github
> ,
> je me dis natural =
> wetland ,
> complété par wetland =
> tidalflat 
> ou wetland =marsh
>  n'est peut-être
> pas une si mauvaise solution. De plus, l'introduction de la page natural
> =wetland
>  fait bien
> référence à des zones humides situées notamment le long de cours d'eau.
>
> Désolé pour mon indécision, je suis tout embrouillé :-S
> Le 28/11/2018 à 10:04, François Boucault a écrit :
>
> @Jérôme Ok pour la clef wikidata...
>
> À propos des tags, voici un résumé des clés principales possibles :
> - natural=shoal 
> / mais le wiki est très peu documenté, il n'y a aucune discussion, et il
> n'est pas fait mention des bancs de rivière, seulement de mer. j'ai tout de
> même trouvé ici  un exemple
> en rivière.
>
> - natural=riverbed
>  / concerne
> plutôt l'entièreté du lit d'une rivière (dépassant du cours "minimum").
> Pour l'utiliser au mieux, il faudrait réduire l'emprise des berges
> (riverbanks), et remplir le vide laissé par une zone "riverbed"
> (correspondant aux bancs de sable). Ça me semble un peu compliqué mais ça
> peut faire sens.
>
> - natural=wetland
>  /
> théoriquement juste, mais sans doute pas assez spécifique
>
> L'avantage de Shoal, c'est qu'il est plus simple à mettre en œuvre que
> riverbed, et qu'il correspond bien à la terminologie utilisée localement
> ("Banc" de sable de Loire). Je vote pour :-)
>
> @Ades natural=shoal peut être complété par différents tags, par exemple
> ici .
>
>
> Le 28/11/2018 à 09:44, ades a écrit :
>
> Si j’ai bien suivi, le plus simple serait de :
> délimiter une surface.
> la tagguer :
> natural = shoal
> seasonal=yes (summer,autumn dans ce cas)
>
> Avec les remarques suivantes :
>
> Parce que la géométrie des bancs de sable varie  chaque saison, mais que
> leur emplacement est grosso modo stable, je proposerai bien que le dessin
> de la surface soit limité à la zone la plus près de la rive (ou au centre
> dans le cas de bancs isolé au milieu du riverbank).
>
> Autrement dit, on ne dessinerait que la partie la plus élevée du banc
> celle qui bouge le moins d’une année sur l’autre, autrement la donnée
> serait impossible à maintenir ;-) sauf à faire un relevé GPS tous les mois,
> et merde… l’accès et le survol est interdit d’avril à août.
>
> D’autant plus valable que pour 2 ou 3 grèves isolées que je connais bien,
> en trois ou quatre ans le chenal, est passé de la rive droite à la rive
> gauche et 

Re: [Talk-it] Uso del tag Disused e rendering

[Sergio Manzi]

Non c'è nulla di sbagliato, ma disused:landuse=quarry è, mi pare, 
semanticamente equivalente e di conseguenza dovrebbe essere reso nello stesso 
modo...

Ciao!

On 2018-11-28 13:46, matteocalosi wrote:
> non vedo cosa ci sia di sbagliato in un landuse=quarry + abandoned=yes

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

Re: [OSM-talk-fr] Places PMR ?

[Christian Quest]

Bonjour Hélène,

Voici une requête overpass qui permet de facilement visualiser ces places:

https://overpass-turbo.eu/s/E5t

On voit via overpass que sur Paris, une partie des arrondissements a été 
importée, mais pas tous: https://overpass-turbo.eu/s/E5v


Elle prend en compte:

- amenity=parking_space + wheelchair=yes/only

- amenity=parking/parking_space + capacity:disabled=1..9


Sur le rendu FR ces tags sont en principe rendus, mais bien sûr le 
placement d'objets faits que l'icône peut être masquée par autre chose 
et elle n'est pas forcément non plus très mise en avant...


Exemple: 
https://tile.openstreetmap.fr/?zoom=20=48.80492=2.48482=B00FF




Le 28/11/2018 à 11:23, Hélène PETIT a écrit :

Bonjour à tous !
Je suis désormais confrontée à la nécessité de localiser une place pmr 
avant d'entreprendre de me déplacer en voiture.


J'ai relu un certain nombre de pages du wiki, mais la question du 
rendu est peu abordée.


Quels sont les fonds de carte qui font apparaître ces données :
https://www.data.gouv.fr/fr/reuses/integration-des-donnees-dans-openstreetmap-et-visualisation-stationnement-pmr/ 



Merci !


Le 18/03/2018 à 19:39, PanierAvide a écrit :

Bonjour,

En lisant le wiki, je me rends compte que pour décrire les places de 
parking individuelles (amenity=parking_space), on est pas sensé 
pouvoir utiliser les variantes de capacity:*=* [1], mais plutôt 
restreindre avec des critères d'accessibilité plus classiques.


En ce qui concerne les places PMR, j'ai pour habitude de renseigner 
un combo amenity=parking_space + capacity:disabled=1 + wheelchair=yes 
(si la place est vraiment accessible, ce qui n'est pas toujours le 
cas). J'ai cru comprendre qu'il y avait aussi possibilité d'utiliser 
parking_space=disabled.


Ma question est la suivante : quelle est donc la bonne pratique sur 
la question des places PMR ? Car ça vaudrait le coup de s'accorder et 
de l'expliciter sur le wiki :-)


Cordialement,

Adrien.

[1] https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dparking_space




___
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: [Talk-it] Chiusura fontanelle a Roma

[antonyb]

Una buona notizia..
Ad oggi posso dire che le fontanelle le hanno riaperte tutte anche quelle
che erano rotte e addirittura le hanno anche riverniciate.



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

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

Re: [OSM-talk-fr] Les voies vertes

[Jérôme Seigneuret]

Dans tous les cas dans le code de la route n'a jamais fait mention de
priorité mais comme tu dois être maître de ton véhicule, c'est les
tribunaux et la jurisprudence et le code des assurance qui font dire que le
piéton est prioritaire. Tu dois anticiper un risque pour l'éviter. Si la
volonté de se faire fracasser est édicté (cas du mec qui se jette sous tes
roues) dans ce cas ta responsabilité est écartée (si tu as des témoins).

Avec les trains c'est l'accident de personne
En bagnole c'est une mise en examen pour violences volontaires avec arme
par destination ou coup et blessure involontaire avec arme par
destination...

Pour rester dans le contexte:

Une voie verte est signalisé par des panneaux réglementaire

c'est un track dans le cas de passage accepté de véhicules de services ou
d'ayants droits mais tu dois avoir un panonceau impérativement. Si il n'y a
pas de panonceau c'est forcément un path

le fait d'avoir foot=designated et bicycle=designated c'est que des
panneaux annoncent l'accessibilité par une signalisation visibible à ces
modes de déplacements.

Bonne journée




Le mer. 28 nov. 2018 à 13:29, lau  a écrit :

> Bonjour,
>
> la priorité d'abord piéton, puis cycliste, puis véhicules motorisés est
> induite par un bout de phrase ajouté en 2008 dans l'article suivant :
> *Article R412-6 *
> I.-Tout véhicule en mouvement ou tout ensemble de véhicules en mouvement
> doit avoir un conducteur. Celui-ci doit, à tout moment, adopter un
> comportement prudent et respectueux envers les autres usagers des voies
> ouvertes à la circulation. *Il doit notamment faire preuve d'une prudence
> accrue à l'égard des usagers les plus vulnérables. *
>
> On peut discuter sur le fait que devoir faire preuve de prudence n'est pas
> équivalent à donner la priorité...
>
> D'après la définition de la voie verte dans le Code de la route, le piéton
> y est aussi légitime que le cycliste (sauf si des panneaux mentionnent le
> contraire, comme sur la voie verte d'Annecy par exemple cf leur brochure
> https://www.lac-annecy.com/voie-verte-lac-annecy.html ), mais l'article
> R412-6 donne au piéton un petit avantage sur le cycliste :)
>
> Autant sur la zone de rencontre la définition précise que le piéton a le
> droit de circuler sur la chaussée (et tant qu'il est en mouvement, n'a pas
> à se rabattre si un véhicule arrive, puisqu'il y est prioritaire, c'est le
> principe de la zone de rencontre, il n'a juste pas le droit de s'arrêter,
> contrairement à l'aire piétonne), autant la façon dont il doit se comporter
> sur la voie verte n'est pas précisé dans le code de la route.
>
> Cordialement,
>
> Laurence
>
>
>
> Le 28/11/2018 à 12:36, Gwenaël Jouvin a écrit :
>
> Bonjour,
>
> Les graphismes de ces panneaux (B 52 et C 115) sont trompeurs et ne reflètent 
> pas véritablement la réglementation.
>
> S’il y a en effet une différence de dimension entre les pictogrammes, en zone 
> de rencontre le piéton est prioritaire sur tous les véhicules. Il peut se 
> déplacer librement sur la chaussée mais doit veiller à ne pas faire entrave à 
> la circulation.
> En zone de rencontre, contrairement à ce que suggère le signal et à ce qui 
> prétendent certaines « références » (y compris en association de cyclistes 
> !), le cycliste ne bénéficie d’aucune priorité particulière sur les autres 
> conducteurs.
>
> Sur une voie verte c’est un peu plus flou car si c’est bien une route, elle 
> est tout de même dédiée aux piétons.
> Sur une route normale, le piéton peut marcher sur la chaussée *par 
> exception*. Je crois que sur une voie verte, ce caractère exceptionnel n’a 
> plus lieu d’être.
>
> Les définitions de ces concepts sont à retrouver à l’article R. 110-2 du code 
> :https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI23095873=LEGITEXT06074228
>
> Méfiez-vous des sites gouvernementaux type sécurité-routière ou 
> service-public, ils sont pleins d’approximations. Le seul avantage est d’y 
> retrouver les articles de référence.
>
> Gwenaël
>
>
> Le 28/11/2018 à 09:19, Pierre L. a écrit :
>
> Bonjour,
>
> Le 27/11/2018 à 20:04, Axelos a écrit :
>
> Dans cette logique, je rappelle juste que la voie verte est considéré
> comme étant une route et non pas un chemin d’après le code de la route,
> et que les cyclistes, en plus de tenir leurs droites doivent laisser la
> priorité aux piétons. On y retrouve le même concept que les zones de
> rencontres, à la seule différence de l’absence de véhicules motorisées.
>
> Si justement on se base sur le concept des zones de rencontres, il y a
> un code visuel qui montre de manière explicite "un piéton (adulte ou
> enfant), en premier plan, puis un cycliste et un conducteur dans sa
> voiture qui les laisse passer vise à montrer clairement la priorité
> piétonne dans l’idée de partage de la voirie à vitesse réduite."
> Page 6 du pdf 
> :http://www.securite-routiere.gouv.fr/content/download/3189/28063/version/1/file/guide_techn_fiche3_technique_zone_rencontre_cle0262fe.pdf
> 

[Talk-it] Estrarre percorso

[antonyb]

Vorrei sapere se è possibile estrarre un percorso di una linea da questo
sito: https://muoversiaroma.it/it/linea?numero=64 ho cercato nel codice
della pagina ma non ho trovato nulla... in genere prendo i percorsi da
questo sito gli open data https://romamobilita.it/it ma in caso di
cambiamenti di percorsi i dati venogno aggiornati dopo qualche giorno. Mi
chiedo anche dove avranno questi dati più aggiornati.
Grazie.



--
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] Tablet con Osmand al posto del navigatore per il 118

[antonyb]

Ti racconto la mia esperienza: 
da più di 4 anni uso un vecchio tablet economico Asus in modalità aereo (non
ho dati) funziona tutto molto bene, quando sono a casa aggiorno le mappe una
volta al mese, anche dentro roma con vie strette e palazzi vicini funziona
molto bene. Ti rimane il problema dei numeri civici che sulle mappe
scarseggiano, ma se man mano li aggiungi tu oltre a contribuire in osm avrai
la perfezione.



--
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-de] Boundary Kreise und Kreisfreie Städte

[Rolf Eike Beer]

Am 2018-11-27 21:20, schrieb wambac...@posteo.de:
Hi, das ist ganz einfach: Der Amtliche Gemeindeschlüssel von Kreisen 
und

Kreisfreien Städten ist unterschiedlich lang.

Der AGS von Kreisen hat die Länge 8 und der von Kreisfreien Städten ist
exakt 5 Zeichen lang. Das gilt für ganz Deutschland.


Nach deiner Tabelle ist es genau andersherum.


 name  | admin_level |
de:amtlicher_gemeindeschluessel
---+-+-
 Halle (Saale) | 6   | 15002000
 Munich    | 6   | 09162000
 Kreis Groß-Gerau  | 6   | 06433
 Kreis Euskirchen  | 6   | 05366
 Landkreis Peine   | 6   | 03157
 Landkreis Neustadt an der Aisch-Bad Windsheim | 6   | 09575
 Landkreis Neunkirchen | 6   | 10043
 Landkreis Neumarkt in der Oberpfalz   | 6   | 09373
 Landkreis München | 6   | 09184
 Landkreis Mühldorf am Inn | 6   | 09183
 Landkreis Miesbach    | 6   | 09182
 Landkreis Neu-Ulm | 6   | 09775
 Landkreis Neustadt an der Waldnaab    | 6   | 09374
 Passau    | 6   | 09262000
 Landkreis Eichsfeld   | 6   | 16061
 Landkreis Ebersberg   | 6   | 09175
 Landkreis Dingolfing-Landau   | 6   | 09279
 Landkreis Dillingen an der Donau  | 6   | 09773
 Landkreis Diepholz    | 6   | 03251
 Landkreis Deggendorf  | 6   | 09271
(20 Zeilen)


Eike

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

Re: [Talk-it] Uso del tag Disused e rendering

[matteocalosi]

Il problema dei lifecycle prefix col rendering è che sono stati introdotti
originariamente proprio per cambiare tag perché il rendering non venga
fatto, per esempio di amenity varie non più aperte. Dato che di fatto li usa
poca gente non ho visto molto interesse quando ho fatto qualche richiesta
riguardo a realizzare un render per elementi per così dire strutturali che
invece non dovrebbero scomparire, ad esempio building o quarry. 
Personalmente li uso solo nei casi in cui ci può essere ambiguità su quale
tag è interessato dal disused, abandoned etc, altrimenti non vedo cosa ci
sia di sbagliato in un landuse=quarry + abandoned=yes 



--
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-ca] Multiple university departments in one building

[James]

Yeah I did that with the indoor tagging schema

On Wed., Nov. 28, 2018, 7:40 a.m. john whelan  Have a look at OSMand and see what it looks like.
>
> Generally it is considered bad practise to map for the renderer.
>
> As an alternative take a look at Place d'Orleans shopping center in
> Orleans Ontario each unit is mapped in outline with the appropriate tags
> added.
>
> If you look at mapping a building with floors I've seen office outlines
> before now.
>
> Cheerio John
>
> On Tue, 27 Nov 2018, 8:00 pm Tim Elrick 
>> Hello,
>>
>> I am trying to contribute to filling the gaps on McGill campus on OSM at
>> the moment and I ran into a problem which I haven't fund a satisfactory
>> answer for yet.
>>
>> We have several buildings on campus which are home to multiple
>> departments, all buildings have a building name.
>>
>> I looked the OSM wiki feature pages and in the OSM forum and found the
>> following approach as apparently standard procedure:
>> 1) Map building outline with building = university , name= XYZ building,
>> operator=McGill University
>> 2) Add a node inside the building for each department with
>> office=university, description=department name
>> This produces irritating blue dots in the outline of the building, see
>> https://osm.org/go/cIrNt~j2u
>>
>> When I looked at other universities, I found e.g. a node with
>> amenity=university, name=department name. But when looking at the OSM
>> wiki feature page for universities[1] it says you only should use
>> amenity=university for the whole campus.
>>
>> The office tag I found when looking for multiple businesses in one
>> building, but the blue dot aren't nice.
>>
>> Any suggestions on how to map this elegantly?
>>
>> Thank you,
>> Tim (aka AGeographer)
>>
>> [1] https://wiki.openstreetmap.org/wiki/Tag:amenity=university
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] bancs de sable dans fleuves et rivières [était] grèves Loire

[François Boucault]

Précision concernant natural=riverbed : le fait d'ajouter aux bancs de
sable une relation "en tant que inner" au polygone "La Loire" réduit de
fait l'emprise des rives, et crée une facilement une différence entre le
cours d'eau et son lit saisonnier. Taguer avec riverbed est sans doute
plus simple que ce que j'écrivais dans mon dernier mail.

Et sinon en lisant cette réponse à l'issue github
,
je me dis natural
=wetland
, complété
par wetland =tidalflat
 ou wetland
=marsh
 n'est
peut-être pas une si mauvaise solution. De plus, l'introduction de la
page natural =wetland
 fait bien
référence à des zones humides situées notamment le long de cours d'eau.

Désolé pour mon indécision, je suis tout embrouillé :-S

Le 28/11/2018 à 10:04, François Boucault a écrit :
>
> @Jérôme Ok pour la clef wikidata...
>
> À propos des tags, voici un résumé des clés principales possibles :
>
> - natural=shoal
>  / mais le
> wiki est très peu documenté, il n'y a aucune discussion, et il n'est
> pas fait mention des bancs de rivière, seulement de mer. j'ai tout de
> même trouvé ici  un
> exemple en rivière.
>
> - natural=riverbed
>  /
> concerne plutôt l'entièreté du lit d'une rivière (dépassant du cours
> "minimum"). Pour l'utiliser au mieux, il faudrait réduire l'emprise
> des berges (riverbanks), et remplir le vide laissé par une zone
> "riverbed" (correspondant aux bancs de sable). Ça me semble un peu
> compliqué mais ça peut faire sens.
>
> - natural=wetland
>  /
> théoriquement juste, mais sans doute pas assez spécifique
>
> L'avantage de Shoal, c'est qu'il est plus simple à mettre en œuvre que
> riverbed, et qu'il correspond bien à la terminologie utilisée
> localement ("Banc" de sable de Loire). Je vote pour :-)
>
> @Ades natural=shoal peut être complété par différents tags, par
> exemple ici .
>
>
> Le 28/11/2018 à 09:44, ades a écrit :
>> Si j’ai bien suivi, le plus simple serait de : 
>> délimiter une surface.
>> la tagguer : 
>> natural = shoal
>> seasonal=yes (summer,autumn dans ce cas)
>>
>> Avec les remarques suivantes : 
>>
>> Parce que la géométrie des bancs de sable varie  chaque saison, mais
>> que leur emplacement est grosso modo stable, je proposerai bien que
>> le dessin de la surface soit limité à la zone la plus près de la rive
>> (ou au centre dans le cas de bancs isolé au milieu du riverbank). 
>>
>> Autrement dit, on ne dessinerait que la partie la plus élevée du banc
>> celle qui bouge le moins d’une année sur l’autre, autrement la donnée
>> serait impossible à maintenir ;-) sauf à faire un relevé GPS tous les
>> mois, et merde… l’accès et le survol est interdit d’avril à août.
>>
>> D’autant plus valable que pour 2 ou 3 grèves isolées que je connais
>> bien, en trois ou quatre ans le chenal, est passé de la rive droite à
>> la rive gauche et vice versa. Le chenal de l’an dernier est une
>> grande zone de sable cette année. Si l’ortho datait de cet été, on
>> « boucherait » ce qui sera peut-être le chenal de l’an prochain.
>>
>> Pour des zones plus stables, là ou sont des « bras morts » ont peut
>> peut-être envisager de « remplir «  la zone avec ‘nature:Shoal’, sans
>> doute à condition que le filaire de la rivière soit représenter.
>>
>> Enfin, si ‘shoal’ me plait bien, il est un peu restrictif par rapport
>> à ‘natural:reiverbed’ qui permet de tagger du sable, de la vase ou
>> m^me de kla végétation temporaire.
>>
>>> Le 27 nov. 2018 à 21:32, Jérôme Seigneuret
>>> mailto:jerome.seigneu...@gmail.com>> a
>>> écrit :
>>>
>>> J'ai pas bien compris ta réponse JB.
>>>
>>> Oui le tag wikidata est le bon
>>> wikidata=Q28337 suffira en replacement de la description
>>>
>>> pour plus de détails tu peux préciser le wikidata sur la clé concernée
>>>
>>> natual:wikidata=Q28337
>>>
>>> Maintenant que je vois la description du wikidata je me dis qu'en
>>> fait c'est juste une erreur de tag car shoal et la traduction de
>>> banc de sable et natural=shoal existe dans osm
>>>
>>> Donc le wikidata n'a plus de sens et il faut remplacer la valeur de
>>> natural
>>>
>>> tidal et tidal flat c'est uniquement en lien avec les marais... et
>>> non avec les crues des cours d'eau et les pépôt d'alluvions (@ades
>>> j'ai lu en travers)
>>>
>>> Bonne soirée
>>>
>>>

Re: [OSM-talk-fr] Les voies vertes

[lau]

Bonjour,

la priorité d'abord piéton, puis cycliste, puis véhicules motorisés est 
induite par un bout de phrase ajouté en 2008 dans l'article suivant :


*Article R412-6 *
I.-Tout véhicule en mouvement ou tout ensemble de véhicules en mouvement 
doit avoir un conducteur. Celui-ci doit, à tout moment, adopter un 
comportement prudent et respectueux envers les autres usagers des voies 
ouvertes à la circulation. *Il doit notamment faire preuve d'une 
prudence accrue à l'égard des usagers les plus vulnérables. *


On peut discuter sur le fait que devoir faire preuve de prudence n'est 
pas équivalent à donner la priorité...


D'après la définition de la voie verte dans le Code de la route, le 
piéton y est aussi légitime que le cycliste (sauf si des panneaux 
mentionnent le contraire, comme sur la voie verte d'Annecy par exemple 
cf leur brochure https://www.lac-annecy.com/voie-verte-lac-annecy.html 
), mais l'article R412-6 donne au piéton un petit avantage sur le 
cycliste :)


Autant sur la zone de rencontre la définition précise que le piéton a le 
droit de circuler sur la chaussée (et tant qu'il est en mouvement, n'a 
pas à se rabattre si un véhicule arrive, puisqu'il y est prioritaire, 
c'est le principe de la zone de rencontre, il n'a juste pas le droit de 
s'arrêter, contrairement à l'aire piétonne), autant la façon dont il 
doit se comporter sur la voie verte n'est pas précisé dans le code de la 
route.


Cordialement,

Laurence



Le 28/11/2018 à 12:36, Gwenaël Jouvin a écrit :

Bonjour,

Les graphismes de ces panneaux (B 52 et C 115) sont trompeurs et ne reflètent 
pas véritablement la réglementation.

S’il y a en effet une différence de dimension entre les pictogrammes, en zone 
de rencontre le piéton est prioritaire sur tous les véhicules. Il peut se 
déplacer librement sur la chaussée mais doit veiller à ne pas faire entrave à 
la circulation.
En zone de rencontre, contrairement à ce que suggère le signal et à ce qui 
prétendent certaines « références » (y compris en association de cyclistes !), 
le cycliste ne bénéficie d’aucune priorité particulière sur les autres 
conducteurs.

Sur une voie verte c’est un peu plus flou car si c’est bien une route, elle est 
tout de même dédiée aux piétons.
Sur une route normale, le piéton peut marcher sur la chaussée *par exception*. 
Je crois que sur une voie verte, ce caractère exceptionnel n’a plus lieu d’être.

Les définitions de ces concepts sont à retrouver à l’article R. 110-2 du code :
https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI23095873=LEGITEXT06074228

Méfiez-vous des sites gouvernementaux type sécurité-routière ou service-public, 
ils sont pleins d’approximations. Le seul avantage est d’y retrouver les 
articles de référence.

Gwenaël


Le 28/11/2018 à 09:19, Pierre L. a écrit :

Bonjour,

Le 27/11/2018 à 20:04, Axelos a écrit :

Dans cette logique, je rappelle juste que la voie verte est considéré
comme étant une route et non pas un chemin d’après le code de la route,
et que les cyclistes, en plus de tenir leurs droites doivent laisser la
priorité aux piétons. On y retrouve le même concept que les zones de
rencontres, à la seule différence de l’absence de véhicules motorisées.

Si justement on se base sur le concept des zones de rencontres, il y a
un code visuel qui montre de manière explicite "un piéton (adulte ou
enfant), en premier plan, puis un cycliste et un conducteur dans sa
voiture qui les laisse passer vise à montrer clairement la priorité
piétonne dans l’idée de partage de la voirie à vitesse réduite."
Page 6 du pdf :
http://www.securite-routiere.gouv.fr/content/download/3189/28063/version/1/file/guide_techn_fiche3_technique_zone_rencontre_cle0262fe.pdf
disponible depuis cette page :
http://www.securite-routiere.gouv.fr/connaitre-les-regles/la-route-la-rue/le-code-de-la-rue2

En se basant sur ce fait, on voit sur le panneau de la "voie verte" un
cycliste en premier plan, on pourrait comprendre à la priorité du vélo
sur le piéton.

S'il faut choisir cycleway ou footway pour représenter toutes voies
vertes, ce serait footway qui devrait être privilégié.

Vu le cycliste représenté au premier plan, cycleway donc... ;)

Cependant, je n'ai pas réussi à mettre la main sur un texte qui
stipulerait que ce soit l'un ou l'autre (piéton/vélo) qui soit
"prioritaire" sur ces voies vertes. En testant le site
www.legifrance.gouv.fr, je trouve que c'est un bordel sans nom pour
chercher une info...

Un petit mot cependant par ici...
https://af3v.org/-Code-du-bon-usage-des-voies-vertes-.html


___
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


--
Laurence Picado
laupic...@posteo.net
07 83 15 49 07

___
Talk-fr mailing list

Re: [Talk-de] service=driveway für alles was service ist?

[Tom Pfeifer]

Die Wiki-Seite wurde auf Ein- und Auffahrten fokussiert.

Ich hatte vor einiger Zeit mal auf 'tagging' angeregt, ein service=* subtag für die übergeordneten 
Servide-roads zu definieren, die in Carto als 'major' gemappt werden, damit die 
Vollständigkeitsfanatiker etwas zu taggen haben, wenn es eben keine untergeordnete (minor) 
Service-road ist.


tom

On 28.11.2018 10:44, Volker wrote:



Am 28.11.2018 um 10:21 schrieb Martin Koppenhoefer:


sent from a phone


On 28. Nov 2018, at 08:35, Falk Zscheile  wrote:

Dein Verständnis zu driveway deckt sich mit dem meinigen. Das sind auch für
mich kurze Wege/Straßen, die als Zufahrt auf Grundstücke dienen (und keine
darüber hinausgehende Erschließungsfunktion für das Grundstück haben).


ich sehe das driveway auch für private Zufahrten, bei einem Ikea sähe ich den Weg der Anlieferung 
(sofern da nur Bedienstete und Lieferer fahren) evtl. als driveway, die Hauptzufahrten zum 
Parkplatz als nur service und die kleinen Stichstraßen, die nur dem Zugang zu Parkplätzen dienen, 
als parking_aisle


Der og. Wikiedit von 2016 ist problematisch.


Gruß, Martin



+1 Dem ist nichts hinzuzufügen



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

Re: [OSM-talk-fr] Mapathon Brest-Madagascar à Brest 13 décembre 2018

[Lionel Allorge]

> Venez nous aider à cartographier les espaces de Madagascar sur
> OpenStreetMap, la carte du monde collaborative et libre


Bonjour,

Merci pour ce projet. Je vous signale ces images de Madagascar faites
par drone lors d'une mission scientifique et qui donne un aperçu des
routes et pistes malgaches :
https://www.youtube.com/watch?v=mYW8K9CovpQ

Librement.


-- 
Lionel Allorge
Wikimedia France : http://wikimedia.fr
April : http://www.april.org
OpenStreetMap France : http://www.openstreetmap.fr/

« La croyance peut être manipulée.
Seul le savoir est dangereux. »
Frank Herbert - Dune

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

Re: [OSM-talk-fr] Multipolygones, zone de rencontre et rendu

[Gwenaël Jouvin]

Merci pour vos réponses.

Je n’avais pas pensé que passer l’espace en pedestrian conviendrait mais comme 
le dit Christian, ça se tient puisque les chaussées existent toujours.
Ce qui m’a trompé est que sur cette place, soit il n’y a jamais eu de trottoirs 
(côté historique), soit ils ont été supprimés (côté moderne rénové).

Pour le polygone du parc, effectivement il n’y a pas d’emprise nette et ce 
n’est pas un endroit intégralement dédié au stationnement comme pourrait l’être 
un parc de supermarché et si les attributs seraient un peu plus complexes, la 
représentation reste possible avec un mélange de 
parking:lane:right:perpendicular, etc.


Gwenaël


Le 26/11/2018 à 14:31, deuzeffe a écrit :
> Le 26/11/2018 à 10:50, Rpnpif a écrit :
>> Bonjour,
>>
>> C'est vrai que le rendu osm-fr est souvent meilleur. Merci Christian.
>> Comment inciter les gens qui s'occupent de celui d'osm.org à le
>> modifier ?
> 
> En demandant ici : https://github.com/gravitystorm/openstreetmap-carto/issues 
> après avoir vérifié qu'il n'y avait pas d'autre demande du même style ?
> 

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

Re: [OSM-talk-fr] Les voies vertes

[Gwenaël Jouvin]

Bonjour,

Les graphismes de ces panneaux (B 52 et C 115) sont trompeurs et ne reflètent 
pas véritablement la réglementation.

S’il y a en effet une différence de dimension entre les pictogrammes, en zone 
de rencontre le piéton est prioritaire sur tous les véhicules. Il peut se 
déplacer librement sur la chaussée mais doit veiller à ne pas faire entrave à 
la circulation.
En zone de rencontre, contrairement à ce que suggère le signal et à ce qui 
prétendent certaines « références » (y compris en association de cyclistes !), 
le cycliste ne bénéficie d’aucune priorité particulière sur les autres 
conducteurs.

Sur une voie verte c’est un peu plus flou car si c’est bien une route, elle est 
tout de même dédiée aux piétons.
Sur une route normale, le piéton peut marcher sur la chaussée *par exception*. 
Je crois que sur une voie verte, ce caractère exceptionnel n’a plus lieu d’être.

Les définitions de ces concepts sont à retrouver à l’article R. 110-2 du code :
https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI23095873=LEGITEXT06074228

Méfiez-vous des sites gouvernementaux type sécurité-routière ou service-public, 
ils sont pleins d’approximations. Le seul avantage est d’y retrouver les 
articles de référence.

Gwenaël


Le 28/11/2018 à 09:19, Pierre L. a écrit :
> Bonjour,
> 
> Le 27/11/2018 à 20:04, Axelos a écrit :
>> Dans cette logique, je rappelle juste que la voie verte est considéré
>> comme étant une route et non pas un chemin d’après le code de la route,
>> et que les cyclistes, en plus de tenir leurs droites doivent laisser la
>> priorité aux piétons. On y retrouve le même concept que les zones de
>> rencontres, à la seule différence de l’absence de véhicules motorisées.
> Si justement on se base sur le concept des zones de rencontres, il y a
> un code visuel qui montre de manière explicite "un piéton (adulte ou
> enfant), en premier plan, puis un cycliste et un conducteur dans sa
> voiture qui les laisse passer vise à montrer clairement la priorité
> piétonne dans l’idée de partage de la voirie à vitesse réduite."
> Page 6 du pdf :
> http://www.securite-routiere.gouv.fr/content/download/3189/28063/version/1/file/guide_techn_fiche3_technique_zone_rencontre_cle0262fe.pdf
> disponible depuis cette page :
> http://www.securite-routiere.gouv.fr/connaitre-les-regles/la-route-la-rue/le-code-de-la-rue2
> 
> En se basant sur ce fait, on voit sur le panneau de la "voie verte" un
> cycliste en premier plan, on pourrait comprendre à la priorité du vélo
> sur le piéton.
>> S'il faut choisir cycleway ou footway pour représenter toutes voies
>> vertes, ce serait footway qui devrait être privilégié.
> Vu le cycliste représenté au premier plan, cycleway donc... ;)
> 
> Cependant, je n'ai pas réussi à mettre la main sur un texte qui
> stipulerait que ce soit l'un ou l'autre (piéton/vélo) qui soit
> "prioritaire" sur ces voies vertes. En testant le site
> www.legifrance.gouv.fr, je trouve que c'est un bordel sans nom pour
> chercher une info...
> 
> Un petit mot cependant par ici...
> https://af3v.org/-Code-du-bon-usage-des-voies-vertes-.html
> 
> 
> ___
> 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] Cartopartie près d'Aubenas, qui vient ?

[Louis-Julien de la Bouëre]

Bonjour,

Dans le cadre d'un travail autour des questions d'accessibilité en 
milieu rural, nous organisons avec la Maison de la vallée de la Bourges 
une Cartopartie accessibilité (mais pas que) dimanche 1er décembre à 
Burzet https://osm.org/go/xV9EA9Zw-?m=


S'il y a du monde qui veut se joindre à nous ce serait super.

C'est pour nous aussi important de pouvoir passer le relais vers des 
groupes locaux et initier des partenariats.


Plus d'infos là : 
https://maisondevallee.fr/les-evenements/actualites/257-une-cartopartie-pour-decouvrir-ensemble-la-commune


Au plaisir de se croiser dans ce joli coin de France


--
Louis-Julien de la Bouëre
Tiriad
ljbou...@tiriad.org
http://www.tiriad.org
http://carterra.net
http://cartomobilite.net
Portable : 06 58 79 80 56
Twitter : @assotiriad
OpenStreetMap : http://hdyc.neis-one.org/?Ljbouere
Mapillary : https://www.mapillary.com/app/user/ljbouere

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

Re: [OSM-talk-fr] Les voies vertes

[jabali]

Je ne pense pas que l'un soit prioritaire par rapport à l'autre.
si c'était le cas, le non prioritaire, le toléré, serait taggué *=yes
Par exemple:
highway=footway
bicycle=yes

Si les 2 sont équivalents alors nous sommes dans le cas d'un "chemin" à la
fois cycleway et footway ( avec séparation ou pas)
Pour le tagguer il y a 3 façons qui sont sémantiquement égales.

1-Le chemin générique (path) + les différents utilisateurs autorisés
(foot-bicycle-horse-...)  par la signalétique(designated)

2-un cycleway ( je rappelle que c'est la même chose que highway=path,
bicycle=designated)
+ foot= designated

3- un footway (idem, même chose que highway=path,foot=designated)
+ bicycle=designated

ensuite la spécificité voie verte (C-116)

Personellement, bien que je sois cycliste assidu,( donc inévitablement avec
un angle de vue orienté) je préfère utiliser le générique
highway=path
bicycle=designated
foot=designated



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Places PMR ?

[Hélène PETIT]

Bonjour à tous !
Je suis désormais confrontée à la nécessité de localiser une place pmr 
avant d'entreprendre de me déplacer en voiture.


J'ai relu un certain nombre de pages du wiki, mais la question du rendu 
est peu abordée.


Quels sont les fonds de carte qui font apparaître ces données :
https://www.data.gouv.fr/fr/reuses/integration-des-donnees-dans-openstreetmap-et-visualisation-stationnement-pmr/

Merci !


Le 18/03/2018 à 19:39, PanierAvide a écrit :

Bonjour,

En lisant le wiki, je me rends compte que pour décrire les places de 
parking individuelles (amenity=parking_space), on est pas sensé pouvoir 
utiliser les variantes de capacity:*=* [1], mais plutôt restreindre avec 
des critères d'accessibilité plus classiques.


En ce qui concerne les places PMR, j'ai pour habitude de renseigner un 
combo amenity=parking_space + capacity:disabled=1 + wheelchair=yes (si 
la place est vraiment accessible, ce qui n'est pas toujours le cas). 
J'ai cru comprendre qu'il y avait aussi possibilité d'utiliser 
parking_space=disabled.


Ma question est la suivante : quelle est donc la bonne pratique sur la 
question des places PMR ? Car ça vaudrait le coup de s'accorder et de 
l'expliciter sur le wiki :-)


Cordialement,

Adrien.

[1] https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dparking_space




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

Re: [Talk-us] Forest Routes

[Minh Nguyen]

On 2018-11-28 01:57, Minh Nguyen wrote:

On 2018-11-20 08:57, Martijn van Exel wrote:
When I map these roads I include the FS number (just the number) as a 
ref, since that is how they are signposted in the field. 


I think the ref tag on the ways should have a prefix and not just 
consist of a bare number. Otherwise, it's just as ambiguous for data 
consumers as the (123) refs all over New Jersey, since the U.S. doesn't 
have a highway tag that corresponds one-for-one with forest routes.


(I hit send too soon.) Lots of shields show only the number and no 
prefix, such as the U.S. Route shield, but we still use the "US" prefix 
anyways.


Data consumers really should be using route relations instead of ref 
tags on ways whenever possible. Some ambiguity is unavoidable on way 
refs, which IMO should reflect what's on plain-text signage or in 
publications. If one thinks of the way refs as a compatibility shim, 
then "FS" doesn't seem unreasonable as a prefix.

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



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