Re: [Talk-es] Necesidad de poner límites en ciudad.

[yo paseopor]

El hecho de poner un límite a las calles es útil, pero en este caso tiene
un problema. Si especificas el límite a 50 km/h y el límite real es a 30 o
a 40 estarás dando una información errónea. Si no especificas límite
sabremos que esas calles las debemos de completar/revisar.

La normativa de tráfico es muy clara: 50 km/h en vías urbanas. No necesitas
un GPS que te lo especifique. Por lo tanto, con o sin datos el máximo en
vía urbana en España (no sólo Granada) será de 50 km/h. Por lo que no ganas
nada poniendo límites a cascoporro (porque este límite se sobreentiende).
El 50 ya lo tienes.
Sería interesante revisar la velocidad de las calles de Granada, a fin de
poner el límite real en las calles.Aprovechad para poner la iluminación
también si esta existiera (lit=yes)

Por lo que hace referencia a las categorías poner de entrada lo que diga un
ayuntamiento o administración sobre una vía puede fallar más que una
escopeta de feria. Ahora bien, tener en cuenta esos datos, aprender, ver
hacia dónde hace ir los flujos de tráfico el ayuntamiento, etc. me parece
correcto y una forma adecuada de proceder, puesto que esos datos nos darán
también las pistas sobre futuras actuaciones en determinadas vías
(pacificaciones, etc.)

Espero que mi opinión te haya servido :)
yopaseopor
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-br] Site do Guia do OSM - https://guiaosmbr.webnode.com/

[Ao Vivo]

Boa Noite a todos.

A Titulo de Informação estou aqui divulgando o Site Guia OSM-BR um Site
com Ferramentas, Tutorias e Noticias do Mundo OSM.

O Site tem a proposta de divulgar ferramentas, noticias e tutorias para
ajudar os mapeadores na hora do mapeamento, o site tem varias ferramentas
que ajuda os mapeadores na verificação, validação e correção dos seus
mapeamentos.

Peço a todos os Mapeadores que divulgue o Site
https://guiaosmbr.webnode.com/ para outros mapeadores para que a comunidade
possa crescer cada vez mais!!

Att;
Um Forte Abraço,

*Raphael de Assis*
Recife/PE.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-es] Necesidad de poner límites en ciudad.

[Fco . Javier González Jiménez]

Hola,

Recientemente un usuario ha modificado todas las categorías de las calles 
urbanas que recorren la ciudad de Granada
argumentando que así las tiene Movilidad del Ayuntamiento. Por mi parte, creo 
que no es correcto trasladar la informa-
ción de organismos oficiales de forma literal, porque muchas veces se pueden 
basar en otras especificaciones o caracterís-
ticas a las que usamos en OSM o incluso pueden ser erróneas, además de 
considerar que la cartografía está bastante tra-
bajada por usuarios anteriores en base a datos oficiales, conocimiento local, 
lógica, etcétera, que creo que es lo que aporta
un plus a nuestra cartografía.

En cualquier caso, le hice hincapié en la necesidad de al menos establecer los 
límites de velocidad, aunque sea el genérico
de 50 km/h para que los enrutadores puedan gestionar la información de forma 
correcta, pero no tuve éxito.

Me gustaría si es posible desde aquí establecer la "obligación" de establecer 
límites de velocidad en las vías de categorías
superiores a residencial a la hora de establecer una red de distribución dentro 
de un municipio.

¿Qué os parece?

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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Martin Koppenhoefer]

sent from a phone

> On 27. Oct 2018, at 17:41, Volker Schmidt  wrote:
> 
> importando in alcune zone ben limitate questi 140 mila alberi, che, in più in 
> tanti casi non corrispondono a nessun albero sul terreno.


in questo caso va rimosso l’albero da osm. Se ci sono resti, potrebbe essere 
convertito in natural=tree_stump
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree_stump

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

Re: [Talk-dk] Fodgængertunnel

[Troels Arvin]

Hej,

Niels skrev bl.a.:
> Så forbind trapperne til İzmir Çanakkale Yolu

Det har jeg nu gjort (synes jeg):
https://www.openstreetmap.org/#map=19/39.54962/26.61866

Men alligevel ledes man som fodgænger fortsat ud på en stor omvej, så 
måske har jeg alligevel ikke gjort det ordentlig?

https://www.openstreetmap.org/directions?engine=graphhopper_foot=39.55069%2C26.61871%3B39.54941%2C26.61845#map=17/39.54930/26.61377

-- 
Troels


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

Re: [Talk-us] New United States Bicycle Routes!

[OSM Volunteer stevea]

Only a couple of minor errors, it's good we double-check one another:  KYTC 
spreadsheet Lines 18/19/20 are a loop that excluded Sand Cave and Cathedral 
Domes in Mammoth Caves National Park, I fixed it so this portion of the route 
is now included in USBR 23.  In Franklin, Spreadsheet line 54 advises 
continuing straight onto KY-73E West Cedar Street (you had a southerly jog onto 
South Main Street, then a quick right onto West Madison Street).  You almost 
had this right, but again, because of some wonky names (and very few ref=* 
tags, both CR  for county-designated roads and KY YYY being frequently 
missing for KYTC-designated roads) I can see how it was easy to miss these 
couple of turns.  I'm pretty sure I have correct this as well, though 
Kentucky's existing TIGER data compared to how KYTC (and locals) "now" name 
these roads indicates a SIGNIFICANT drift in names and ref=* numbering (where 
they even exist at all) in the last 11 years.

If there one single US state which quickly rises (imo) to Priority 1, needing 
IMMEDIATE attention to fix its TIGER data, it is Kentucky.  I revise my 
characterization of these data from yesterday's "fair to poor" to simply "poor."

I probably made similar errors on my entry of USBR 21 in Kentucky, including a 
road/rail-undercrossing I'm still not sure truly exists!

If you are reading this and live/work in Knox County, Warren County and/or the 
City of Franklin in Kentucky, OSM sure could use a "triple-check" of these 
data, or even a comprehensive effort at statewide TIGER Review with state- and 
county-level road naming/numbering authorities.  Thank you in advance!

SteveA
California

> On Oct 27, 2018, at 2:30 PM, OSM Volunteer stevea  
> wrote:
> 
> Thanks, Greg, I'm now "double-check reviewing" USBR 23 in Kentucky.  Thanks 
> for your reciprocity on 21 (when/as you get your 'net back, of course).
> 
> SteveA
> California
> 
>> On Oct 27, 2018, at 11:38 AM, Greg Morgan  wrote:
>> 
>> I will be happy to review your implementation of the route. A second pass is 
>> always good for these turn by turn routes. It will have to wait until later 
>> in the day. I have an internet outage right now. 
> 


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

Re: [Talk-us] New United States Bicycle Routes!

[OSM Volunteer stevea]

Thanks, Greg, I'm now "double-check reviewing" USBR 23 in Kentucky.  Thanks for 
your reciprocity on 21 (when/as you get your 'net back, of course).

SteveA
California

> On Oct 27, 2018, at 11:38 AM, Greg Morgan  wrote:
> 
> I will be happy to review your implementation of the route. A second pass is 
> always good for these turn by turn routes. It will have to wait until later 
> in the day. I have an internet outage right now. 

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

Re: [Talk-dk] Fodgængertunnel

[Niels Elgaard Larsen]

On 27/10/2018 16.48, Troels Arvin wrote:
> Hej,
> 
> Niels skrev bl.a.:
>> Du skal bare tagge selve tunnelen den med highway=footway og trapperne
>> med highway=steps
> 
> OK, så sådan her?
> https://www.openstreetmap.org/changeset/63937315#map=19/39.54969/26.61796
> 
> (I min opmærkning er det lidt sært, at trapperne ligesom fører op til 
> ingenting. Der er jo et fortov, som de fører op til, men fortovet er ikke 
> mærket op separat, og jeg har ikke mulighed for at opmærke fortovene 
> ordentlig, fordi jeg ikke længere er i området.)

Så forbind trapperne til İzmir Çanakkale Yolu

Fortovene er ikke mærket op og der er ikke en access restriktion på
Trunk vejen, der forbyder fodgængere. Så rutere vil lede fodgængere ad
den store vej, selvom de i praksis vil gå på fortovet.

Til gengæld har fodgængere brug for at kunne krydse den store ved og her
kommer tunnelen ind.

Se på:


https://www.openstreetmap.org/directions?engine=osrm_car=39.55041%2C26.61893%3B39.54948%2C26.61839#map=17/39.54978/26.61606

Når du forbinder trapperne til hovedvejen bliver det en del kortere.


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

Re: [Talk-dk] Fodgængertunnel

[Troels Arvin]

Hej,

Niels skrev bl.a.:
> Du skal bare tagge selve tunnelen den med highway=footway og trapperne
> med highway=steps

OK, så sådan her?
https://www.openstreetmap.org/changeset/63937315#map=19/39.54969/26.61796

(I min opmærkning er det lidt sært, at trapperne ligesom fører op til 
ingenting. Der er jo et fortov, som de fører op til, men fortovet er ikke 
mærket op separat, og jeg har ikke mulighed for at opmærke fortovene 
ordentlig, fordi jeg ikke længere er i området.)

-- 
Troels


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

[Talk-se] Liten ordlista för OSM-deltagare

[egil]

Hej :)

Jag har efter några år i OSM börjat fundera lite på hur vi bäst 
översätter engelska uttryck som förekommer i gemenskapen.


Här kommer en liten lista över ord som jag valt att översätta med länkar 
till den svenska Wiktionary:


* **bug** ⇒ fel, [bugg](https://sv.wiktionary.org/wiki/bugg)

* **mapper** ⇒ OSM-are, 
[kartläggare](https://sv.wiktionary.org/wiki/kartläggare)


* **render** ⇒ [rendering](https://sv.wiktionary.org/wiki/rendering)

* **render bug** ⇒ 
[renderingsfel](https://sv.wiktionary.org/wiki/renderingsfel)


* **tag** ⇒ [tagg](https://sv.wiktionary.org/wiki/tagg)

* taggstatus kan vara: i användning, övergett, godkänt, utkast, till 
diskussion (RFC)


Utifrån detta kan ord som dessa skapas: fellagd, felrendering, 
feltaggat, tagga om, taggdokumentation, ...


Vad tycker ni? Kom gärna med förslag och kommentarer.

Mvh

Egil/pangoSE


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

Re: [Talk-it] hotel che è anche ristorante

[liste DOT girarsi AT posteo DOT eu]

Il 27/10/18 22:13, demon.box ha scritto:

ciao, se ho un hotel che offre anche servizio come ristorante aperto a tutti,
visto che non è detto che sia sempre così nel senso che il ristorante di un
hotel non è detto che sia aperto anche a chi non risiede nell'hotel mi pare
un'aspetto importante da segnalare.
detto questo, aggiungo un altro nodo a se stante come amenity=restaurant
oppure sullo stesso nodo farò

tourism=hotel + amenity=restaurant ?

grazie



Sì, il building sicuramente hotel, un nodo solo dove è il ristorante.



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

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

[Talk-it] hotel che è anche ristorante

[demon.box]

ciao, se ho un hotel che offre anche servizio come ristorante aperto a tutti,
visto che non è detto che sia sempre così nel senso che il ristorante di un
hotel non è detto che sia aperto anche a chi non risiede nell'hotel mi pare
un'aspetto importante da segnalare.
detto questo, aggiungo un altro nodo a se stante come amenity=restaurant
oppure sullo stesso nodo farò

tourism=hotel + amenity=restaurant ?

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

Re: [Talk-dk] Fodgængertunnel

[Niels Elgaard Larsen]

On 27/10/2018 15.48, Troels Arvin wrote:
> Hej,
> 
> Jeg vil gerne indtegne en fodgængertunnel her:
> https://www.openstreetmap.org/#map=19/39.54950/26.61800
> 
> Sådan ser det ud:
> http://troels.arvin.dk/osm/evidence/turkey/ped_tun/foto.jpg
> 
> Jeg vil gerne sikre mig, at jeg ikke ved en fejl kommer til at tagge det 
> på en måde, hvor navigationssystemer pludselig tror, at man kan foretage 
> en U-vending i tunnellen eller lign.



Du skal bare tagge selve tunnelen den med highway=footway
og trapperne med highway=steps

> Jeg tænker, at denne måde at gøre det på ikke er god nok:
> http://troels.arvin.dk/osm/evidence/turkey/ped_tun/osm-ss.png
> 
> Måske bør jeg med access=* gøre ét eller andet for at indikere, at biler 
> ikke kan køre der? Eller markerer jeg strækningen som værende både en 
> fodgænger-sti og tunnel, hvorved det implicit er givet, at tunnellen ikke 
> er til biler?

Netop

> 


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

[Talk-it] quale barrier?

[demon.box]

ciao, spesso mi imbatto in questo tipo di rozza barriera fatta di grossi
rami, messa volutamente per disincentivare il passaggio per lo meno di moto
e mtb, come taggarlo?

 

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-dk] Fodgængertunnel

[Troels Arvin]

Hej,

Jeg vil gerne indtegne en fodgængertunnel her:
https://www.openstreetmap.org/#map=19/39.54950/26.61800

Sådan ser det ud:
http://troels.arvin.dk/osm/evidence/turkey/ped_tun/foto.jpg

Jeg vil gerne sikre mig, at jeg ikke ved en fejl kommer til at tagge det 
på en måde, hvor navigationssystemer pludselig tror, at man kan foretage 
en U-vending i tunnellen eller lign.

Jeg tænker, at denne måde at gøre det på ikke er god nok:
http://troels.arvin.dk/osm/evidence/turkey/ped_tun/osm-ss.png

Måske bør jeg med access=* gøre ét eller andet for at indikere, at biler 
ikke kan køre der? Eller markerer jeg strækningen som værende både en 
fodgænger-sti og tunnel, hvorved det implicit er givet, at tunnellen ikke 
er til biler?

-- 
Troels


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

Re: [OSM-talk-be] official meeting on November 13th

[marc marc]

Le 27. 10. 18 à 21:34, joost schouppe a écrit :

la traduction des 2 parties :

Salut,

Parce que nous avons envoyé ce message très rapidement (à cause de la 
date limite du 28 octobre), il était seulement en anglais. Le courrier 
d'invitation aux membres sera également en français et en néerlandais. 
Mais comme il s'agit déjà d'une annonce officielle, c'est une bonne 
pratique de fournir des traductions. Je vais le faire maintenant pour le 
néerlandais. Si quelqu'un veut répondre par une traduction en français, 
ce serait génial.
Certaines personnes ont été surprises de ne pas se retrouver sur la 
liste des membres. Ceci est basé sur le formulaire "Join" sur osm.be, et 
a ensuite été nettoyé en demandant aux gens de reconfirmer leur adhésion 
un peu plus tard. Malheureusement, le formulaire d'inscription n'est pas 
disponible pour le moment. Si vous avez des questions ou si vous voulez 
vous inscrire maintenant, veuillez communiquer avec moi ou bo...@osm.be

Un autre point à l'ordre du jour : nous examinons actuellement un projet 
quelque peu formel avec la Croix-Rouge flamande. Ce serait un bon moment 
pour s'assurer que personne ne voit de problèmes avec cela.
Et une correction : nous ne "visons pas une semaine", nous avons déjà 
fixé une date et un lieu : Le 13 novembre au "Markten" à Bruxelles.
--
A l'occasion de la reconnaissance d'OpenStreetMap-Belgium comme un 
représentant local officiel de la Fondation OpenStreetMap, nous avons 
pensé qu'il était temps de penser à nouveau à notre organisation. C'est 
l'heure d'une réunion officielle ! Elle aura lieu le 13 novembre. Vous 
pouvez participer en ligne via le canal Riot spécialement pour les 
réunions : https://riot.im/app/#/room/#osmbe-meetings:matrix.org) ou en 
face à face au café De Markten à Bruxelles. L'idée est qu'il s'agit 
d'une réunion comme les réunions habituelles, mais avec un ordre du jour 
officiel. Toute personne qui est membre (ce qui signifie que vous êtes 
sur cette liste : https://members.osm.be/list.php?lang=fr_US) peut 
voter, et nous pouvons voter sur tout ce qui est à l'ordre du jour. Cet 
ordre du jour doit être clôturé le 29 octobre, alors partagez les points 
à l'ordre du jour dès que possible en répondant ici ou en privé.

Des sujets auxquels nous avons pensés :
 décider d'un code de conduite (proposition disponible sur 
https://github.com/osmbe/working-group-bylaws)

 évaluer le fonctionnement du conseil d'administration : mode de 
fonctionnement, nombre de membres, date des élections ?

 préciser ce que cela signifie d'être membre (exigences minimales, 
mieux expliquer)

 comment avoir plus de membres actifs ?

 les priorités actuelles correspondent-elles à ce que les membres 
veulent ?

 Coopération possible avec la Croix-Rouge flamande

Si vous le souhaitez, vous pouvez vous inscrire via 
https://www.meetup.com/OpenStreetMap-Belgium/events/255829090/
(ou faites-nous le savoir)

Tout le monde est le bienvenu ! Mais pour voter, il faut être membre 
depuis 60 jours. Vous pouvez le vérifier via http://members.osm.be/list.php

Les membres recevront une autre invitation par la poste.

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

Re: [OSM-talk-be] official meeting on November 13th

[joost schouppe]

Hi,
Because we sent this message real quick (because of the deadline of Oct
28th) it was only in English. The invite mail to the members will also be
in French and Dutch. But since this is already an official announcements,
it's good practice to provide translations. I'll do it now for Dutch. If
anyone wants to reply with a French translation, that would be awesome.
Some people were surprised not to find themselves on the member list. This
is based on the "Join" form on osm.be, and was subsequently cleaned by
asking people to reconfirm their membership sometime later. Unfortunately,
the registration form is down at this time. If you have any issues or want
to register now, please contact me or bo...@osm.be

One more agenda item by now: we are looking into a somewhat formal project
with the Flemish Red Cross. It would be a good time to make sure no one
sees issues with that.
And a correction: we don't "aim for a week", we've already set a date and
place: November 13th at "de Markten" in Brussels.
---

Ter gelegenheid van het feit dat OpenStreetMap-Belgium nu een officieel
Local Chapter van de OpenStreetMap Foundation is, vonden we het tijd om nog
eens na te denken over onze organisatie. Tijd voor een officiële
bijeenkomst! Deze zal doorgaan op 13 november. Je kan online deelnemen via
het Riot-kanaal speciaal voor meetings:
https://riot.im/app/#/room/#osmbe-meetings:matrix.org) of face to face in
café De Markten in Brussel . Het idee is dat het een bijeenkomst is zoals
de gewoonlijke meetups, maar met een officiële agenda. Iedereen die lid is
(wat betekent dat je op deze lijst staat:
https://members.osm.be/list.php?lang=en_US) kan stemmen, en we kunnen
stemmen over alles wat op de agenda staat. Deze agenda moet afgesloten
worden op 29 oktober, dus deel eventuele agendapunten zo snel mogelijk door
hier or privé te antwoorden.

Topics waar we zelf aan dachten:
* beslissen over een code of conduct (voorstel staat op
https://github.com/osmbe/working-group-bylaws)

* de werking van de board evalueren: manier van werken, aantal leden,
wanneer verkiezingen?

* verfijnen wat het betekent om lid te zijn (minimumvereisten, beter
uitleggen)

* hoe meer leden actief krijgen?

* huidige prioriteiten en sluiten ze aan bij wat de leden willen?

* mogelijke samenwerking met het Vlaamse Rode Kruis

Als je dat wil, dan kan je inschrijven via
https://www.meetup.com/OpenStreetMap-Belgium/events/255829090/
(of laat het weten)

Iedereen is welkom! Maar om te stemmen moet je al 60 dagen lid zijn. Je kan
dit nakijken via http://members.osm.be/list.php

Leden krijgen nog een uitnodiging per mail.


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

Re: [Talk-us] New United States Bicycle Routes!

[Greg Morgan]

I will be happy to review your implementation of the route. A second pass
is always good for these turn by turn routes. It will have to wait until
later in the day. I have an internet outage right now.

I found Kentucky surprising when I have gone to visit. I am used to the
open road of the western states. Barrow pits on either side of the road are
used to build the road bed. In Kentucky it is very common to have a
gigantic tree at the edge of the road...well the minor roads. As I recall
all the roads leading into Lexington form spokes to a hub. These roads were
the horse trails to the tobacco markets. The roads in Kentucky have a very
different feel.

I will check both routes to the latest version of tiger data. I am not sure
that will help. As far as I know, the city, county, and states feed their
data to the census. If the data isn't that good to begin with or there has
been rapid changes, then you are going to run into the issues that you
describe. I have had to search for key roads in a number of states to
complete various USBRs. Kentucky also feels different because the counties
are the driving governments as I recall. If counties do not have thousands
and thousands of dollars for ESRI software to maintain the data, then you
will have these issues.

I also found some areas of poverty remarkable. The anti-importers want to
write studies that the Tiger import killed the community when in fact the
real issue is that we do not have the same density of mappers as some
locations in Europe. In the case of Kentucky parts of it are so rural that
a person is lucky to have phone service. Adding information to OSM is a
leisure class activity of time and resources.  I remember fields and fields
of tabacco crops years ago. The same areas have no cash crops.

I am not alarmed at the condition of Tiger data in Kentucky especially when
you consider parts of the state.


On Fri, Oct 26, 2018, 3:31 PM OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> I have completed a first draft of USBR 21 in Kentucky.  This was actually
> quite difficult as the TIGER name tags frequently do not match what highway
> names on the application from Kentucky's DOT says.  I did not change these,
> I'll leave that for "locals," but there is a great deal of work to do to
> change highway names in OSM in Kentucky, as it appears that counties,
> cities and KDOT change names (and segment breaks that make them up) quite a
> lot in the last 11 years since TIGER data were entered.
>
> As our wiki says and as is good practice in OSM, Greg's 23 and my 21 data
> entry deserve a "double-check review" by another OSM volunteer, and while
> these are "green" in our wiki, they are a "light green" until this is
> completed.  Greg, if you email me off list and agree to double-check 21,
> I'll do the same to 23.  Others are welcome, of course; email one or both
> of us if you are interested in helping.
>
> SteveA
> California
>
> > On Oct 26, 2018, at 10:51 AM, OSM Volunteer stevea <
> stevea...@softworkers.com> wrote:
> >
> > Wow, Greg, you are quick.  Thank you!
> >
> > Additionally, (a major reason I'm including Kerry in this missive), I
> removed from OSM segments of Kentucky's USBR 23 which overlapped with ACA's
> Transamerica Trail (TA) "Mammoth Cave Loop."  (Now largely superseded by 76
> and 23).  These were between Highland Springs ("mid-state") and further
> north to Tanner, where 23 now connects to 76 at a T-intersection.  There
> are many reasons why OSM has been deprecating ACA routes in OSM:  these are
> proprietary and likely don't belong in OSM first place, and we document in
> our wiki that "over time, these tend to be replaced by USBRs" (among other
> reasons, like that they can get old and drift from updates that ACA can
> make or already has made).  Indeed, once again (as in the case of the
> northern segment of 76 in Kentucky replacing Mammoth Caves Loop earlier
> when 76 was approved in Kentucky), this segment of 23 100% overlaps with
> this ACA route, so yet another significant ACA route segment now deleted
> from OSM (as it is USBR now).
> >
> > Thanks again for your work to enter this, and keep up the great entry
> I'm guessing you are doing with USBR 21.
> >
> > Steve
> >
> >> On Oct 26, 2018, at 6:18 AM, Greg Morgan 
> wrote:
> >>
> >> Kentucky USBR 23  is done.
> https://www.openstreetmap.org/relation/8843677#map=10/37.4960/-85.4712
> >
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Migrer les amenity=swimming_pool (le retour)

[Paul Desgranges]

Normalement tu ne devrais plus trouver de "amenity=swimming_pool ayant 
un tag leisure/name/building", puisque justement c'était l'étape d'avant


Par contre j'ai cherché à l'instant les "amenity=swimming_pool" de type 
node seulement sur overpass-turbo https://overpass-turbo.eu/s/D9Q
et les premiers cas regardés ne peuvent pas être transformés directement 
en "leisure=swimming_pool"  !
- https://www.openstreetmap.org/node/1820461288 celui-ci c'est un 
"leisure=sports_centre + sport=swimming"
- https://www.openstreetmap.org/node/3648626536 celui-ci c'est un 
"leisure=sports_centre + sport=swimming"
- https://www.openstreetmap.org/node/1904181893 celui-ci c'est un 
bassin, mais il est déjà taggué comme bassin, et il est à coté d'un 
établissement qui n'est
pas taggué comme  "leisure=sports_centre + sport=swimming", et c'est 
plutôt ça qu'il faudrait faire du coup

-  et les autres que j'ai regardé aussi ...

Donc je crains que la conversion massive soit un peu risquée.

Il faudrait au moins couper en deux le traitement :
 - les nodes d'un coté (il y en a 102 
), par nature on ne peut pas connaître 
leur superficie :  j'ai l'impression qu'il faudrait regarder chacun des 
cas ? et dans n'y aurait-il pas un outil qui permettrait de se répartir 
la charge ?
 - les ways d'un autre coté (il y en a 6120 
), il faut les traiter en fonction de 
leur superficie
   -- les grandes superficies sont à regarder au cas par cas (par 
exemple https://www.openstreetmap.org/way/129407009

 est à transformer en "leisure=swimming_area")
   -- les petites superficies je ne sais pas en fait, regarder si on ne 
peut pas exploiter la présence d'un autre tag : 'phone=*' ou 
'access=customers' ou 'covered=yes' ?



Je pars une semaine, donc je ne pourrais pas participer à la suite de 
ceci la semaine prochaine en tout cas.

A bientôt
Paul



>Le 27/10/2018 /à 17:51:09 2018/, Marc marc a écrit :
> J'avais déjà passé en revue le critère des 2000m2 mais
> il peux toujours y avoir de nouveaux cas entre temps.
>De toute façon, je proposais de le faire avec ceinture
>et bretelles. et donc ces cas sont ignorés dans ma correction.
>Si personne n'a plus d'objection, je ferrai la conversion
> des amenity=swimming_pool n'ayant pas de tag leisure/name/building,
>ayant une surface < 2000m2 et situé en France
>en leisure=swimming_pool

Le 27/10/2018 à 15:55, Paul Desgranges a écrit :
Voilà ! J'ai fait ce dont on avait parlé (voir ci-dessous), donc il 
n'y a plus de "amenity=swimming_pool + name=*" ni de 
"amenity=swimming_pool + building=*" (sauf erreur ?)
(l'occasion à chaque fois de faire un peu de micromapping autour de 
ces établissements...)


Ce que je n'ai pas fait, c'est le traitement de tous les 
"amenity=swimming_pool" qui auraient une surperficie assez grande pour 
suspecter un "leisure=sports_centre",
cela reste une étape supplémentaire à faire avant le changement massif 
des autres "amenity=swimming_pool" ?


Bonne journée
Paul




je regarde de mon coté tous les cas qui sont exclus de l'édition de 
masse

Si je devais le faire

1- Je corrigerais d'abord les piscines avec un champ nom 'Piscine'
'Piscine privée' pour mettre ça dans la "description"
2- J'enlèverais du traitement massif tout ce qui peut l'être (comme
mentionné) :   les amenity=swimming_pool nommés (sauf les noms 
m. ci-dessus à traiter individuellement)   les 
amenity=swimming_pool qui sont aussi building

  les amenity=swimming_pool qui sont aussi leisure=sports_centre
 Car tous ceux là ont vocation à devenir des "leisure=sports_centre
sports=swimming name=... building=...", (sauf exception donc avec une

vérification visuelle)

3- Je regarderais à la mano les amenity=swimming_pool qui sont aussi
leisure=*
et puisque tu es partant pour le reste, que moi je considère bcp plus 
risqué, et bien ça se complète pas trop mal




___
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-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[yo paseopor]

On Sat, Oct 27, 2018 at 2:06 AM Santiago Higuera  wrote:

> Lo siento, yopaseopor, no me convencen tus argumentos, me sigue
> pareciendo mejor el procedimiento actual para clasificar las carreteras
> que el que tú propones.
>

Contra eso no puedo decir nada más que: respeto pero no comparto tu
opinión. De todas formas gracias por participar en el debate.
Saludos
yopaseopor
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-se] Fwd: Re: [Tagging] Upcoming removal of power=station and power=sub_station in the standard style

[egil]

Hej

Jag undrar om det är nån som har något emot att jag massändrar 
sub_station->substation enl. nedan i SE.

Totalt 198 objekt.

Mvh
Egil/pangoSE

 Forwarded Message 
Subject: 	Re: [Tagging] Upcoming removal of power=station and 
power=sub_station in the standard style

Date:   Mon, 22 Oct 2018 10:06:36 +0700
From:   Dave Swarthout 
Reply-To: 	daveswarth...@gmail.com, Tag discussion, strategy and related 
tools 

To: Tag discussion, strategy and related tools 



It would seem an easy fix to change all power=sub_station tags to 
power=substation without an individual inspection. The other tag, 
power=station, is much more problematical because one cannot know for 
sure if that tag is correct.


I think most new mappers already use the newer tagging guidelines but 
I'm not sure what mechanism you could use to get the message out to all 
concerned.


Dave

On Mon, Oct 22, 2018 at 8:22 AM Daniel Koć > wrote:


   Hi,

   It has been noted that we still render power=station and
   power=sub_station in OSM Carto, even if they are both deprecated and
   replacement tags are much more popular by now:

   
https://github.com/gravitystorm/openstreetmap-carto/issues/3305#issuecomment-414058220


   I would be happy to get rid of them eventually, but I'd like to take
   some time before doing that, because they still have some share in a
   database:

   - power=station - 5 016 uses -
   https://wiki.openstreetmap.org/wiki/Tag%3Apower%3Dstation

   - power=sub_station - 17 514 uses -
   https://wiki.openstreetmap.org/wiki/Tag:power%3Dsub_station


   Could we reduce their usage further now (or maybe even eradicate them)?


   -- 
   "Excuse me, I have some growing up to do" [P. Gabriel]




   ___
   Tagging mailing list
   tagg...@openstreetmap.org 
   https://lists.openstreetmap.org/listinfo/tagging



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

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[yo paseopor]

Hola

> Lo que hecho en falta es una propuesta clara y a ser posible concisa y
> en la wiki. Y que valga para toda España.
>

Creo que una propuesta como esta, más o menos parecida, con más o menos
parámetros, pero con la misma intencionalidad la he escrito en esta lista
mínimo 6 veces. Todas ellas han tenido ,al final de una correspondencia
bastante intensa, una oposición vehemente especialmente por parte de
algunos miembros de la comunidad lo cual ha hecho que la gran mayoría de
datos, de observaciones y de desarrollos de la propuesta se quede en agua
de borrajas.

En algunas de las anteriores propuestas se ha hecho trabajo también con la
wiki, de hecho existen algunas de esas páginas como por ejemplo
[1].
Incluso se ha conseguido la categorización en otras vías que no fueren de
Fomento por parte de la comunidad OSM de algunas autonomías.

Te puedo contar que personalmente yo creo en esta propuesta , por ello de
la propuesta en la wiki tengo un esbozo. Pero también te puedo decir que
dado el resultado de las últimas 5 veces no la he perfilado del todo en la
wiki...para que después no se apruebe. La he explicado en lista
extensamente (y no es la primera vez que lo hago) y sólo le faltan detalles
por configurar y acabar de ajustar.

-La propuesta vale para toda España (un IMD provincial tiene el mismo
significado aquí que en Murcia, y por supuesto vale para cualquier
administración)
-La propuesta es concisa: usar los estudios de tráfico de Fomento (IMD,
velocidad media, características de la vía) para determinar si las
carreteras de Fomento deben seguir siendo trunk, especialmente aquellas que
tienen una alternativa libre de pago de doble plataforma como recorrido
paralelo.

Saludos
yopaseopor

[1] https://wiki.openstreetmap.org/wiki/ES:Normalizaci%C3%B3n_f%C3%ADsica
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] signification multiple crossing=zebra

[deuzeffe]

Hello,

Si j'ai bien compris ae pour crossing=zebra -> crossing_ref=zebra ?

Pas d'objection.
--
deuzeffe, qui va continuer à nettoyer sa zone...

On 25/10/2018 23:51, marc marc wrote:

Bonjour,

j'aurais du vous proposer une édition de masse sur ce sujet.
c'était en préparation depuis longtemps depuis que le problème avait été
identifié lors d'une discussion cartomobilité qui discute entre autre
des problèmes de comment osm peux aider pour renseigner l'accessibilité
multiple.
mais voila, ces oir josm a poussé un patch qui complique encore la
chose. je vais donc vous exposer le problème en français, traduction
de celui que je viens de poster sur tagging (la ml mondiale anglaise
pour les problèmes de tag).

Bonjour. Bonjour,

J'ai un gros problème avec crossing=zebra.
il empêche de remplir d'autre valeur pour le croisement comme
crossing=traffic_signals (passage piéton avec un feu de circulation)
crossing=uncontrolled (passage piéton sans feu)
le wiki[1] dit que crossing=zebra est un raccourci pour
crossing=uncontrolled + crossing_ref=zebra au Royaume-Uni
mais beaucoup de zébra tant au Royaume-Uni, qu'en France et ailleur
ont des zébra avec feu qui doivent donc être renseign avec
crossing=traffic_signals
donc à la fin, crossing=zebra n'a pas de sens... peut-être
que le contributeur précédent voulait dire crossing=uncontrolled +
crossing_ref=zebra
mais peut-être qu'il veut dire seulement crossing_ref=zebra et qu'il n'a
aucune idée de la présence de feu ou pas (ajout depuis l'imagerie sat
par exemple).
J'ai corrigé il y a quelques semaines beaucoup de crossing=zebra
crossing_1=signals_traffic_signals
ou crossing=zebra;traffic_signals qui montrent que c'est un problème.

un ticket a été fermé dans iD[2] il y a quelque temps parce que "son dev
n'aime pas crossing_ref" (c'est en fait un nom très laid pour le tag)
en ce moment josm[3] change le preset pour supprimer cossing_ref=zebra
en faveur du croissing=zébra

Je fais partie d'un groupe de cartographes travaillant sur
l'accessibilité yant l'intention d'ouvrir une discussion pour y
remédier, mais l'actualité des commit nous a précédés.

donc ma requête est : comment éviter à nouveau une balise multi sens ?

Peut/doit-on séparer le type de croisement du marquage au sol ?
en résumé : changer les crossing=zebra au profit d'une autre balise ?
si oui crossing_Ref est-il si laid que dans le même temps un autre tag
en a besoin à utiliser pour le marquage au sol ?
(ajout hors traduction : perso je suis partisant d'étape limité séparée
et donc initialement j'aurais changer crossing=zebra en
crossing_ref=zebra et reporté le choix d'un meilleur non pour le
marquage dans un autre sujet)

évitons l'argument "il y a trop de cas à régler",
cela ne m'effraie pas de proposer une édition de masse une fois qu'un
schéma cohérent a été établi.
mais le fait d'avoir la moité des outils qui remplissent une valeur avec
une autre signification que l'autre ou que la signification historique
est un gros problème pour l'utilisation. des données.

[1] https://wiki.openstreetmap.org/wiki/Key:crossing
[2] https://github.com/openstreetmap/iD/issues/4788
[3] https://josm.openstreetmap.de/ticket/16793
https://taginfo.openstreetmap.fr/search?q=%3Dzebra

Cordialement,
Marc
___
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] tracciamo il futuro di OpenStreetMap in Italia?

[Maurizio Napolitano]

Ciao a tutt*
sulla base delle discussioni nate in questa ML e del documento che
abbiamo condiviso che si trova qui
https://hackmd.io/obMDTskMTnynK7U4YcvMRg
ho redatto la pianificazione 2019 di Wikimedia Italia.
Il documento è qui
https://wiki.wikimedia.it/wiki/Associazione:Pianificazione_2019/OSM
Ne hanno accesso solo i soci di WMI.

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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Cascafico Giovanni]

Si esegue la conflation su natural=tree e denotation!=null

L'eventuale doppione (definito dai tag sopra ed in un certo raggio max) non
viene importato, ma i tag considerati "master" vanno a rimpiazzare o ad
aggiungersi al nodo preesistente.

Alla fine ci saranno 140,000 più una-due centinaia, ma quelli importati
avranno un ref inequivocabile, che li distingue per il futuro disboscamento.

Il sab 27 ott 2018, 17:42 Volker Schmidt  ha scritto:

> Ci sono de aspetti che non son stati menzionati, mi sembra:
> (1) Che cosa facciamo per capire se un albero da importare è un doppione
> di un albero già presente in OSM
> (2) Ci sono in OSM (nel Veneto) in qualcosa come 140 mila alberi (
> http://overpass-turbo.eu/s/D9M)
>
> Il problema, già sollevato e discusso in passato a più riprese, è che il
> tag natural=tree secondo il wiki dovrebbe essere " A single *tree*,
> sometimes lone or significant."
> ma è stato utilizzato per rendere più bella la mappa al posto di landuse,
> importando in alcune zone ben limitate questi 140 mila alberi, che, in più
> in tanti casi non corrispondono a nessun albero sul terreno.
> Se adesso aggiungiamo alberi monumentali con lo stesso tag, facciamo la
> confusione totale.
> Prima dell'import dobbiamo pulire la mappa di gran èparte di questi 140
> mila alberi "decorativi"
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Migrer les amenity=swimming_pool (le retour)

[marc marc]

J'avais déjà passé en revue le critère des 2000m2 mais
il peux toujours y avoir de nouveaux cas entre temps.

De toute façon, je proposais de le faire avec ceinture
et bretelles. et donc ces cas sont ignorés dans ma correction.

Si personne n'a plus d'objection, je ferrai la conversion
des amenity=swimming_pool n'ayant pas de tag leisure/name/building,
ayant une surface < 2000m2 et situé en France
en leisure=swimming_pool

Le 27. 10. 18 à 15:55, Paul Desgranges a écrit :
> Voilà ! J'ai fait ce dont on avait parlé (voir ci-dessous), donc il n'y 
> a plus de "amenity=swimming_pool + name=*" ni de "amenity=swimming_pool 
> + building=*" (sauf erreur ?)
> (l'occasion à chaque fois de faire un peu de micromapping autour de ces 
> établissements...)
> 
> Ce que je n'ai pas fait, c'est le traitement de tous les 
> "amenity=swimming_pool" qui auraient une surperficie assez grande pour 
> suspecter un "leisure=sports_centre",
> cela reste une étape supplémentaire à faire avant le changement massif 
> des autres "amenity=swimming_pool" ?
> 
> Bonne journée
> Paul
> 
> 
> 
> 
>> je regarde de mon coté tous les cas qui sont exclus de l'édition de masse
>> Si je devais le faire
>>> 1- Je corrigerais d'abord les piscines avec un champ nom 'Piscine'
>>> 'Piscine privée' pour mettre ça dans la "description"
>>> 2- J'enlèverais du traitement massif tout ce qui peut l'être (comme
>>> mentionné) :   les amenity=swimming_pool nommés (sauf les noms m. 
>>> ci-dessus à traiter individuellement)   les amenity=swimming_pool qui 
>>> sont aussi building
>>>   les amenity=swimming_pool qui sont aussi leisure=sports_centre
>>>  Car tous ceux là ont vocation à devenir des "leisure=sports_centre
>>> sports=swimming name=... building=...", (sauf exception donc avec une
>> vérification visuelle)
>>> 3- Je regarderais à la mano les amenity=swimming_pool qui sont aussi
>>> leisure=*
>> et puisque tu es partant pour le reste, que moi je considère bcp plus 
>> risqué, et bien ça se complète pas trop mal
> 
> 
> 
> ___
> 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-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[Lanxana .]

Buenas tardes,

en primer lugar, agradecer a yopaseopor por atreverse a iniciar una vez más
este debate y no tirar la toalla, y un aplauso a Santiago Crespo por
devolvernos al quid de la cuestión.

Como se ha comentado en algún otro correo, en la reunión del pasado día 20,
que se hizo durante la Geocamp (y a la cual asistieron unos presencialmente
y otros remotamente), volvió a salir el tema de la normalización de las
carreteras y la necesidad o no de hacer una revisión que se adapte mejor a
la realidad. Entre los presentes en la reunión se decidió que sí, siempre y
cuando se encuentren unos criterios objetivos y claros para hacerla.

Como ninguno somos expertos en la materia, se le pidió a yopaseopor que
iniciara el debate con una propuesta en la lista, para que aquellos que
tienen más experiencia, ya sea en carreteras o en mapeo, pudieran hacer sus
aportaciones, mejorarla y lograr un consenso entre todos. Leyendo los
mensajes, parece que se está convirtiendo en una cruzada personal de un
miembro contra el resto, y que se intenta "hacer entrar en razón" al
mensajero, olvidándonos del mensaje.

No tengo la respuesta mágica ni voy a extenderme en opiniones y contra
opiniones, tan sólo me gustaría convertir esto en un debate constructivo,
donde se aporten soluciones. Así que ahí van algunas preguntas sobre las
que creo podríamos empezar a trabajar:

1 - ¿Una carretera puede tener diferentes categorías a lo largo de su
trazado?
2 - En la wiki, la definición de "trunk" es suficiente (o demasiado)
ambigua como para interpretarla según los criterios que definamos:  "Use
highway =trunk for high
performance or high importance roads that don't meet the requirement for
motorway . In
different countries, either performance or importance is used as the
defining criterion."  Es decir, tan sólo nos dice que es una vía de gran
capacidad o importancia y que cada país define qué criterio usa para
denominarla así. ¿Qué criterio nos parece mejor: capacidad  o importancia?
3 - ¿Cómo determinamos la capacidad o importancia de una vía? Se ha hablado
de los pros y contras del IMD, del grado de conservación/inversión,
existencia de vías alternativas...
4 - ¿Qué criterios objetivos nos dan idea de la importancia de una vía?
Según leí en su momento, para la red nacional la importancia de una vía la
define la importancia de las ciudades que une. ¿Es este el único criterio?
¿Somos capaces de encontrar otros igual de objetivos?
5 - En los mensajes se ha hablado de anchos de vía, velocidades medias,
estado del pavimento... parámetros objetivos, sí, pero que pueden
etiquetarse como características de la vía (width, maxspeed,
smoothness...). Por otro lado, un parámetro físico y objetivo como la
existencia o no de cruces al mismo nivel, o la separación física entre
sentidos, no se pueden "etiquetar" como característica de la vía. ¿Serían
criterios válidos para medir la importancia de la vía respecto a la red o
no?
6 - ¿La existencia de carreteras con la misma función (unir A y B) implica
necesariamente que se tengan que categorizar de manera distinta? En el caso
de autopista/autovía y carretera parece que hay consenso en que sí, pero ¿y
en el resto de casos?
7 - ¿Dos carreteras con la misma categoría pueden tener características
distintas en cuanto a trazado (más o menos sinuoso, cruces a nivel, etc)
y/o características físicas (ancho de plataforma, rugosidad, velocidad
media, IMD...)?

Espero vuestras respuestas y opiniones, juntos lo lograremos,
Saludos!

El sáb., 27 oct. 2018 a las 15:32, Santiago Crespo (<
openstreet...@flanera.net>) escribió:

> Hola,
>
> Después de leer los 30 correos no puedo resistirme a dar mi opinión,
> aunque nunca he editado una carretera en OSM y ni siquiera tengo el
> carnet :)
>
> Creo que tiene sentido clasificar las carreteras y los tramos por sus
> cualidades físicas e importancia, en lugar de los criterios
> administrativos. Ya sé que existen etiquetas para el estado físico, pero
> highway=* debería reflejar la importancia que tiene una vía en relación
> con otras del entorno y/o del país.
>
> No debería importarnos que una misma carretera pase de highway=trunk a
> highway=loquesea según el tramo, lo importante es representar la
> realidad sobre el terreno.
>
> Para indicar quién administra una carretera está la etiqueta operator=*
> (además de ref=* para el código de referencia oficial).
>
> Lo que hecho en falta es una propuesta clara y a ser posible concisa y
> en la wiki. Y que valga para toda España.
>
> Saludos,
> Santiago Crespo
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Volker Schmidt]

Ci sono de aspetti che non son stati menzionati, mi sembra:
(1) Che cosa facciamo per capire se un albero da importare è un doppione di
un albero già presente in OSM
(2) Ci sono in OSM (nel Veneto) in qualcosa come 140 mila alberi (
http://overpass-turbo.eu/s/D9M)

Il problema, già sollevato e discusso in passato a più riprese, è che il
tag natural=tree secondo il wiki dovrebbe essere " A single *tree*,
sometimes lone or significant."
ma è stato utilizzato per rendere più bella la mappa al posto di landuse,
importando in alcune zone ben limitate questi 140 mila alberi, che, in più
in tanti casi non corrispondono a nessun albero sul terreno.
Se adesso aggiungiamo alberi monumentali con lo stesso tag, facciamo la
confusione totale.
Prima dell'import dobbiamo pulire la mappa di gran èparte di questi 140
mila alberi "decorativi"


On Sat, 27 Oct 2018 at 17:04, Cascafico Giovanni 
wrote:

> Il mio dubbio riguardo al dato "ele" è se (*non so...*) venga sempre
>> visualizzato sulla mappa quando presente.
>>
>
> No, mi pare non sia visualizzato nemmeno se è l'unico tag.
>
> Inoltre, forse, è preferibile utilizzare questo dato solo quando sia
>> certificato (*parliamo comunque di certezza umana...*), come nel caso
>> dell'altezza delle montagne o degli aeroporti.
>>
>
> Personalmente ho aggiunto diversi valori ele ricavati dai dati exif delle
> mie foto. Comunque un'occhiata a campione fa sempre bene.
>
>  Il discorso della certificazione sconvolgerebbe
> tutto osm se fosse applicato: chi ha l'autorità di certificare? quali sono
> le priorità per certificare? quali sono le tolleranze? L'approccio e la
> peculiarità osm sono proprio nel non avere un'autorità centrale. Che
> ciascuno possa essere creatore e controllore finora ha dato risultati non
> male, non credi?
>
> Personalmente faccio (*fortemente*) il tifo per "taxon" che riunisce in
>> se i due termini (Genus + species) della classificazione binomiale [1] (es:
>> "Pinus nigra") e che si presta ad ulteriori specificazioni (es. "*Pinus
>> nigra* var. *austriaca*")
>>
>
> Sono ignorante in materia e probabilmente hai ragione sull'efficienza
> nell'uso di taxon, ma ci troviamo con un dataset che ha come nome del campo
> "nome scientifico" ed i cui valori sono composti da taxon + il nome del/dei
> catalogatori (il più comune è L. > Linneo); direi che il tag corretto
> (senza rielaborazioni) sarebbe species. O no? Togliere quella "L." mi
> sembrerebbe impoverire il risultato; per quel che ho capito, da species si
> può sempre derivare taxon... ma è possibile anche il contrario?
>
> ___
> 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] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Cascafico Giovanni]

>
> Il mio dubbio riguardo al dato "ele" è se (*non so...*) venga sempre
> visualizzato sulla mappa quando presente.
>

No, mi pare non sia visualizzato nemmeno se è l'unico tag.

Inoltre, forse, è preferibile utilizzare questo dato solo quando sia
> certificato (*parliamo comunque di certezza umana...*), come nel caso
> dell'altezza delle montagne o degli aeroporti.
>

Personalmente ho aggiunto diversi valori ele ricavati dai dati exif delle
mie foto. Comunque un'occhiata a campione fa sempre bene.

 Il discorso della certificazione sconvolgerebbe tutto
osm se fosse applicato: chi ha l'autorità di certificare? quali sono le
priorità per certificare? quali sono le tolleranze? L'approccio e la
peculiarità osm sono proprio nel non avere un'autorità centrale. Che
ciascuno possa essere creatore e controllore finora ha dato risultati non
male, non credi?

Personalmente faccio (*fortemente*) il tifo per "taxon" che riunisce in se
> i due termini (Genus + species) della classificazione binomiale [1] (es:
> "Pinus nigra") e che si presta ad ulteriori specificazioni (es. "*Pinus
> nigra* var. *austriaca*")
>

Sono ignorante in materia e probabilmente hai ragione sull'efficienza
nell'uso di taxon, ma ci troviamo con un dataset che ha come nome del campo
"nome scientifico" ed i cui valori sono composti da taxon + il nome del/dei
catalogatori (il più comune è L. > Linneo); direi che il tag corretto
(senza rielaborazioni) sarebbe species. O no? Togliere quella "L." mi
sembrerebbe impoverire il risultato; per quel che ho capito, da species si
può sempre derivare taxon... ma è possibile anche il contrario?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-ca] weeklyOSM #431 2018-10-16-2018-10-22

[weeklyteam]

The weekly round-up of OSM news, issue # 431,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10846/

Enjoy!

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

[Talk-us] weeklyOSM #431 2018-10-16-2018-10-22

[weeklyteam]

The weekly round-up of OSM news, issue # 431,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10846/

Enjoy!

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

[talk-ph] weeklyOSM #431 2018-10-16-2018-10-22

[weeklyteam]

The weekly round-up of OSM news, issue # 431,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10846/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[OSM-talk] weeklyOSM #431 2018-10-16-2018-10-22

[weeklyteam]

The weekly round-up of OSM news, issue # 431,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10846/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-GB] weeklyOSM #431 2018-10-16-2018-10-22

[weeklyteam]

The weekly round-up of OSM news, issue # 431,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10846/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-in] weeklyOSM #431 2018-10-16-2018-10-22

[weeklyteam]

The weekly round-up of OSM news, issue # 431,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/10846/

Enjoy!

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

Re: [OSM-talk-be] osm - arlon - training course / evangelization

[joost schouppe]

Cool!
Let us know how it went.

Op do 4 okt. 2018 om 14:00 schreef Pierre Parmentier <
pierrecparment...@gmail.com>:

> For your information.
>
> I shall deliver some information at the Espace public numérique (EPN)
> d'Arlon  about OpenStreetMap. In
> French.
>
>- 23 October 2018 at 9.00*: Consulter OpenStreetMap*
>- 23 October 2018, at 13.00: *Consulter OpenStreetMap* (same subject)
>- 6 November 2018 at 9.00: *Contribuer à OpenStreetMap*
>- *27 *November 2018 at 9.00: *Contribuer à OpenStreetMap*
>
> Reg
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [Talk-at] Neue Rechtschreibung von Wiener Straßennamen

[Friedrich Volkmann]

On 20.10.2018 13:24, Andreas Geyer-Schulz wrote:

Ich finde es sinnvoll, wenn 'addr:street' stets mit dem 'name' der
entsprechenden Straße übereinstimmt.


Das würde ich nicht generell so sagen, denn addr:street gibt an, wie die 
Straße als Adressbestandteil üblicherweise geschrieben wird, während name=* 
auf der Straße die Schreibweise angibt, die in allen übrigen Nennungen (auf 
Tafeln, in Nachrichten usw.) üblich ist. Die zwei müssen sich nicht 
notwendigerweise decken. Es gibt ja sogar Adressen mit Pseudostraßennamen, 
zu denen gar keine Straße existiert.


Es kann aber oft nicht schaden, Alternativschreibweisen ebenfalls zu taggen:
z.B. name="Nussdorfer Straße" + old_name="Nußdorfer Straße"
und in Adressen mittels addrN-Schema:
addr:street="Nussdorfer Straße", addr2:street="Nußdorfer Straße".
Dieses Schema propagiere ich zwar, aber es erfordert viel Schreibarbeit, 
weil jedes Mal alle addr:-Tags (Hausnr. usw.) nochmal angegeben werden, und 
wenn dort ebenfalls Varianten existieren, dann multipliziert sich das.



Sie sind mir aufgefallen, weil in der Adressansicht des OSM Inspectors
die Adressen nicht zu den Straßennamen passen.


Du hast es richtig gemacht und erst eine Diskussion gestartet. Weil aber 
viele einfach drauf losändern, wenn OSMI etwas als Fehler anzeigt, kann man 
nicht oft genug darauf hinweisen, dass solche Validatoren nur mit Vorsicht 
zu benutzen sind. Viele Prüfungen sind fehlerhaft oder entsprechen nicht den 
Tagging-Standards, sondern nur den verschrobenen Vorlieben der Einzelperson, 
die die Prüfroutine (bzw. die Anzeige einer wertfreien Info als Warnung oder 
gar Fehler) geschrieben hat.



Aber ich bin nicht sicher, wie man nun die Straßennamen schreiben sollte.


Ich auch nicht, aber i.a. scheint sich die neue Rechtschreibung 
durchzusetzen (außer bei offensichtlichen Personennamen).


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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

[OSM-talk-fr] Migrer les amenity=swimming_pool (le retour)

[Paul Desgranges]

Voilà ! J'ai fait ce dont on avait parlé (voir ci-dessous), donc il n'y a plus de 
"amenity=swimming_pool + name=*" ni de "amenity=swimming_pool + building=*" 
(sauf erreur ?)
(l'occasion à chaque fois de faire un peu de micromapping autour de ces 
établissements...)

Ce que je n'ai pas fait, c'est le traitement de tous les "amenity=swimming_pool" qui 
auraient une surperficie assez grande pour suspecter un "leisure=sports_centre",
cela reste une étape supplémentaire à faire avant le changement massif des autres 
"amenity=swimming_pool" ?

Bonne journée
Paul


 


je regarde de mon coté tous les cas qui sont exclus de l'édition de masse
Si je devais le faire

1- Je corrigerais d'abord les piscines avec un champ nom 'Piscine'
'Piscine privée' pour mettre ça dans la "description"
2- J'enlèverais du traitement massif tout ce qui peut l'être (comme
mentionné) : 
  les amenity=swimming_pool nommés (sauf les noms m. ci-dessus à traiter individuellement) 
  les amenity=swimming_pool qui sont aussi building

  les amenity=swimming_pool qui sont aussi leisure=sports_centre
 Car tous ceux là ont vocation à devenir des "leisure=sports_centre
sports=swimming name=... building=...", (sauf exception donc avec une

vérification visuelle)

3- Je regarderais à la mano les amenity=swimming_pool qui sont aussi
leisure=*
et puisque tu es partant pour le reste, que moi je considère bcp plus 
risqué, et bien ça se complète pas trop mal




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

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[Santiago Crespo]

Hola,

Después de leer los 30 correos no puedo resistirme a dar mi opinión,
aunque nunca he editado una carretera en OSM y ni siquiera tengo el
carnet :)

Creo que tiene sentido clasificar las carreteras y los tramos por sus
cualidades físicas e importancia, en lugar de los criterios
administrativos. Ya sé que existen etiquetas para el estado físico, pero
highway=* debería reflejar la importancia que tiene una vía en relación
con otras del entorno y/o del país.

No debería importarnos que una misma carretera pase de highway=trunk a
highway=loquesea según el tramo, lo importante es representar la
realidad sobre el terreno.

Para indicar quién administra una carretera está la etiqueta operator=*
(además de ref=* para el código de referencia oficial).

Lo que hecho en falta es una propuesta clara y a ser posible concisa y
en la wiki. Y que valga para toda España.

Saludos,
Santiago Crespo

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

Re: [OSM-talk] Mobile Application for optimizing OSM ski area data

[Mateusz Konieczny]

26. Oct 2018 14:22 by v...@live.at :


>
> I am planning to develop an mobile app to optimize ski area data provided by 
> OSM. The user should be able to use the app for locating him- or herself in a 
> ski area and have a look at all the different slopes and lifts and all their 
> details.
>




See StreetComplete - https://github.com/westnordost/StreetComplete 





Maybe parts can be done also as SC quests. It is also likely that some 
libraries made by

Westnordost will be useful for you.





>
> What would you recommend regarding authentication? Is it ok if users of my 
> app are committing data on my behalf or should all users have their own OSM 
> account?
>




Do you want to be directly responsible for all edits made by users (not only 
indirectly 


responsible as the editor author)?


 

>
> If users have their own account, is it possible and ok if I prepare the data 
> with my algorithm and commit the data on their behalf?
>




Yes, see StreetComplete. Note that in this case you are fully responsible for 
all mistakes

made by the algorithm (there were already bugs in StreetComplete that resulted 
in review

of all possibly affected changesets).


 

>
> In general, what is your recommendation regarding this kind of third-party 
> integration?
>




See StreetComplete, it works well and code is likely to be reusable (assuming

that you accept the license).



> What do you think of my idea?




I would strongly suggest to start from looking at what can be implemented as a 
StreetComplete

quests - there is already some pool of people using this editor and it may be 
better to start from

the simplest possible task. Making a new editor is a huge effort.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] poliambulatorio e centro medicina dello sport

[Sergio Manzi]

Ciao Volker!

Concordo... parzialmente: non mi sembra che l'esistenza di laboratori e/o 
strutture interventistiche sia necessaria a definire una "clinic". Per me una 
/clinic /è un luogo dove ci sono più medici (una "/shared practice/"). Credo si 
definisca /clinic /anche quello che in Italiano chiamiamo consulto/consultorio.

Sergio


On 2018-10-27 12:33, Volker Schmidt wrote:
> Il confine è fluido fra
>
>   * amenity=clinic e un posto con tanti medici, con laboratori, spesso anche 
> per interventi, ma senza letti per la notte (che in Italia spesso si chiamano 
> "day hospital", ma, attenzione, questo uso del termine inglese in italiano è 
> diverso. Il "day hospital" in UK e USA è tipicamente per anziani)
>   * amenity=doctors è un ambulatorio con almeno un medico, tipicamente senza 
> laboratori o possibilità per interventi
>
>
>
>
>
> On Fri, 26 Oct 2018 at 14:18, demon.box  > wrote:
>
> ciao, un poliambulatorio medico dove ci sono vari medici che effettuano
> visite specialistiche di vario genere (c'è un neurologo, un cardiologo,
> ecc.) lo taggo come amenity=clinic ?
>
> e nel caso invece di un centro con più dottori che eseguono però
> esclusivamente visite per il rilascio del certificato all'attività 
> sportiva
> agonistica e non agonistica, lo taggo come amenity=doctors ?
>
> 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-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-es] Calles residenciales en Madrid

[dcapillae]

Hola, Héctor.

Ikanian ha preguntado cómo etiquetar calles residenciales de un solo sentido
donde las bicis pueden circular en ambos sentidos. En ese caso, bastaría con
añadir «oneway:bicycle=no» al etiquetado de la vía. No ha mencionado que
haya carriles bici ni ninguna otra característica en particular. En general,
con «oneway:bicycle=no» es suficiente para indicar que las bicis pueden
circular a contramano por una vía de sentido único (oneway=yes), es decir,
que puede circular en el sentido propio de la vía y en sentido contrario.

Para conocer el etiquetado de casos particulares, habría que conocer los
detalles para poder precisar.



-
Daniel Capilla 
OSM user: dcapillae 
--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Ciao Giovanni,


On 2018-10-27 10:58, Cascafico Giovanni wrote:
> il ref è del ministero ed usano lo stesso schema in tutti i documenti excel 
> delle regioni, per cui direi
> ref:mipaaft.

Può essere utile aggiungere un riferimento temporale (es.  mipaaft2018) per 
distinguere potenziali successivi import?

> Per ele, il datum non è idefinito. Suppongo sia stato quello che leggevano i 
> rilevatori sul gps. Vedrò di fare qualche campionamento.

Il mio dubbio riguardo al dato "ele" è se (/non so.../) venga sempre 
visualizzato sulla mappa quando presente. In tal caso ci sarebbe il rischio, 
credo, di "/confusionare/" un po' troppo il rendering (/sì, lo so, non si mappa 
per la mappa, ma.../). Inoltre, forse, è preferibile utilizzare questo dato 
solo quando sia certificato (/parliamo comunque di certezza umana.../), come 
nel caso dell'altezza delle montagne o degli aeroporti.

> Sull'uso di species o taxon, avevo inizialmente  considerato la prima, in 
> quanto composta da taxon+catalogatori... aspettiamo qualche altro parere.
> Tra l'altro, per generare taxon ho considerato le prime due parole di 
> species, metodo ok per gran parte dei casi, ma non universalmente applicabile.

Personalmente faccio (/fortemente/) il tifo per "taxon" che riunisce in se i 
due termini (Genus + species) della classificazione binomiale [1] (es: "Pinus 
nigra") e che si presta ad ulteriori specificazioni (es. "/Pinus nigra/ var. 
/austriaca/")

Ciao,

Sergio

[1] https://it.wikipedia.org/wiki/Nomenclatura_binomiale


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

Re: [Talk-es] Calles residenciales en Madrid

[Héctor Ochoa]

Tal y como indica en la wiki,
https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dopposite, con
oneway:bicycle=no no queda claro si hay un carril bici en contradirección o
no. Con cycleway=opposite se indica claramente que no es así, tal y como
pasa en las calles residenciales de Madrid.

Saludos.

El vie., 26 oct. 2018 a las 11:34, dcapillae ()
escribió:

> Hola, Ikanian.
>
> Como dice Polyglot, es suficiente con añadir «oneway:bicycle=no» para
> indicar que las bicis pueden circular indistintamente en ambos sentidos a
> lo
> largo de una vía de sentido único («oneway=yes»). No hace falta nada más.
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>


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

Re: [Talk-it] poliambulatorio e centro medicina dello sport

[Volker Schmidt]

Il confine è fluido fra

   - amenity=clinic e un posto con tanti medici, con laboratori, spesso
   anche per interventi, ma senza letti per la notte (che in Italia spesso si
   chiamano "day hospital", ma, attenzione, questo uso del termine inglese in
   italiano è diverso. Il "day hospital" in UK e USA è tipicamente per anziani)
   - amenity=doctors è un ambulatorio con almeno un medico, tipicamente
   senza laboratori o possibilità per interventi





On Fri, 26 Oct 2018 at 14:18, demon.box  wrote:

> ciao, un poliambulatorio medico dove ci sono vari medici che effettuano
> visite specialistiche di vario genere (c'è un neurologo, un cardiologo,
> ecc.) lo taggo come amenity=clinic ?
>
> e nel caso invece di un centro con più dottori che eseguono però
> esclusivamente visite per il rilascio del certificato all'attività sportiva
> agonistica e non agonistica, lo taggo come amenity=doctors ?
>
> 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-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Cascafico Giovanni]

il ref è del ministero ed usano lo stesso schema in tutti i documenti excel
delle regioni, per cui direi
ref:mipaaft.

Per ele, il datum non è idefinito. Suppongo sia stato quello che leggevano
i rilevatori sul gps. Vedrò di fare qualche campionamento.

Sull'uso di species o taxon, avevo inizialmente  considerato la prima, in
quanto composta da taxon+catalogatori... aspettiamo qualche altro parere.
Tra l'altro, per generare taxon ho considerato le prime due parole di
species, metodo ok per gran parte dei casi, ma non universalmente
applicabile.


Il ven 26 ott 2018, 16:58 Martin Koppenhoefer  ha
scritto:

>
>
> sent from a phone
>
> > On 26. Oct 2018, at 14:14, Cascafico Giovanni 
> wrote:
> >
> > Che ne dite di questo [1] tagging?
> >
> > natural=tree
>
>
> ok
>
>
> > ref=28/l483/UD/06
>
>
> questo lo vedo scritto sull’albero? Io darei un’indicazione di chi è il
> ref, tipo
> ref:xyz=*
>
>
> > circumference=3 
>
>
> ok
>
>
> > ele=170 
>
>
> si riferisce al terreno intorno, vero? È in WGS84, oppure qual’è il
> sistema di riferimento?
>
>
>
> > height=20 
>
>
> ok
>
>
> > leaf_cycle=deciduous 
> > leaf_type=broadleaved 
>
>
> ok
>
>
> > taxon=Cupressus cashmeriana 
> > taxon:it=Cipresso del Cashmere 
>
>
> userei species, e non metterei nomi comuni (it). species è più specifico
> ed è usato 5volte di più rispetto a taxon. Taxon lo vedo come tag
> preliminare se non sai di che livello di classificazione biologica si
> tratta.
>
> Ciao, Martin
> ___
> 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] poliambulatorio e centro medicina dello sport

[Sergio Manzi]

No, è giusto: una /clinic/ Inglese/Americana/Ecc... è una "outpatient's 
facility", non prevede le degenze degenze, e quindi va benissimo in questo caso.

Vedi https://www.dictionary.com/browse/clinic

Ciao!


On 2018-10-27 09:58, scratera wrote:
> ...clinic non lo metterei...specificheresti che ci sono degenti e non mi pare
> il casospecificherei piuttosto con healthcare=centre
>
>
>
> --
> 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: [Talk-it] poliambulatorio e centro medicina dello sport

[scratera]

...clinic non lo metterei...specificheresti che ci sono degenti e non mi pare
il casospecificherei piuttosto con healthcare=centre



--
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-cz] WeeklyOSM CZ 430

[Tom Ka]

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

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

* Registrace na SotM CZ 2018 v Brně!

* Oplocení dálnic od ŘSD.
* Data od měst - Budějovice.
* Import aktualizace poštovních schránek.
* Značení mezinárodních tras.
* Je 255 znaků pro tagy málo?
* Vládní pozemky v landuse.
* Na kole přes Andy.
* Příští volby do rady Nadace OSM.
* Pokyny pro organizované editování.
* Open Location Codes.
* Změny srážek.

Pěkné počtení ...

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

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[yo paseopor]

> 1. Sería una importación de datos. Dudo que fuese bien recibida por la
> comunidad global. A mí no me parece buena idea en principio, entre otras
> razones por la dificultad del mantenimiento.
>
> 2. Salvo que mappers se pusiesen a calcular IMD's (lo dudo muchísimo),
> sería un dato sólo recabable de Fomento. Seguir importando.
>
> Saludos,
>
> Rafael.
>
1- Me gustaría aclarar que usar un dato como base para la categorización de
otro no tengo claro que sea importación. Esto sería importante , no sólo
para las carreteras sino para el resto de elementos del mapa.
En el caso de la propuesta la IMD de una vía enfrente de la IMD de otras
serviría para determinar los usos que se dan de una vía en una zona (este
sistema vale para toda administración: 1 vehículos por día son 1
vehículos). En ningún caso se pretende importar los datos ni de IMD ni de
velocidad media (las características físicas ya están en el mapa).

2- ¿Consultar datos es importar?
3- ¿Las dificultades de mantenimiento (todos los edificios de España, todas
las vías de España, todas las calles de España, todos los caminos de
España, todas las gasolineras de España...) nos deben impedir mapear un
elemento? ¿Ese es un criterio a seguir por la comunidad? ¿La dificultad?

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