Re: [Talk-us] cardinal directions

[Paul Johnson]

On Wed, Jan 18, 2017 at 8:59 AM, Martijn van Exel  wrote:

> I am trying to be consistent with the outcome of the discussion that we
> had on talk-us a couple of years ago. Right now both are used
> (north/south/east/west as relation member role as well as direction on the
> relation tag) but the former is used way more often. That’s why I am
> suggesting going with the practice that has surfaced as the most popular,
> as well as the outcome of earlier discussion.
>
> Perhaps I am not understanding you correctly, but I am *not* suggesting to
> use tags on ways to indicate cardinal direction, just assign roles to
> relation members. Agreed that adding this type of info to ways makes it
> impossible to validate / maintain.
>

Right, I think we're on the same page.  I'm also suggesting it's high time
we revisited the issue as the tools to handle managing
north/east/south/west roles (as opposed to forward/backward) just plain
never materialized.  If it was going to happen, it would have already
happened (it's been years!).


> This also does not have to preclude having separate e/w or n/s relations +
> a super relation — I think that is actually good practice for big relations
> to keep them manageable.
>

 Pretty much have to for any relation that has a dual carriageway at one
end and is more than a few ways long.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Green Mountain National Forest cleanup

[Adam Franco]

Thanks for those details, Kevin. The comparison is very helpful. The GMNF
seems to have only 3 classifications that I've been able to find:

   - Wilderness -- which should probably be protected_class=1b
   - National Recreation Area -- protected_class=5 (Wikipedia page
   
   notes the ICUN class)
   - everything else -- probably protected_class=6

Thanks again for the feedback!

On Wed, Jan 18, 2017 at 12:15 AM, Kevin Kenny 
wrote:

> On Tue, Jan 17, 2017 at 8:59 PM, Adam Franco  wrote:
>
>> Thanks for another fabulously detailed reply Kevin!
>>
>> So it sounds like I'm on the right track then and it makes sense to leave
>> the broad outer boundaries as *boundary=national_park* and use the 
>> *boundary=protected_area
>> + leisure=nature_reserve* combo for the smaller US Forest Service-owned
>> parcels.
>>
>
> That's what I did when I reimported the Adirondack and Catskill data.
> There wasn't a clear consensus that the tagging was 'right' - but nobody
> really complained after the job was done.
>
> The tagging that I used is described in http://wiki.openstreetmap.org/
> wiki/NYS_DEC_Lands
> In the Catskills, there was a second category of public land:
> http://wiki.openstreetmap.org/wiki/Import:_NYCDEP_Watershed_
> Recreation_Areas
>
> I believe that it will be important, if anyone does get around to using
> the protected_area tagging, that protect_class and protection_object be
> something reasonable; that's something that's likely to affect the
> rendering. I'm not all that familiar with GMNF, so I don't know if there
> are a range of protection classes in it the way there are in the New York
> forests.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] an important piece of information

[Hanns Mattes]

Dear, 


Here is some important information I've picked especially for you, you may read 
it here http://tommso.oregoncoastbridges.com/1213


Hanns Mattes

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

[OSM-talk] wow, extremely good news!

[Henk Hoff]

Hello, 

I've just read something  really good,  you're going to be surprised!  That's 
just awesome,  read it  here please http://vincenzo.entertainmentlinx.com/2524


Yours truly, Henk Hoff

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

[OSM-talk] SOTM EU

[Martijn van Exel]

Hi all, 

I am curious — are there plans for a SOTM EU this year?

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

[Talk-es] Debate sobre señales y herramientas para gestionarlas en OSM. Petición de ayuda

[yo paseopor]

Buenas gente!

Ya hemos visto que Santiago Crespo ha hecho peticiones que han sido
resueltas afirmativamente (aunque aún no definitivas del todo) en una misma
dirección: Señales verticales. Y dado que la petición ha sido realizada a
la Dirección General de Carreteras la respuesta ha sido información sobre
las que son de su competencia.Estamos hablando de que han contestado las
resoluciones con un documento excel con 673.024 que se reparten por todas
las comunidades autónomas, con más de 700 códigos diferentes. También se ha
respondido una petición sobre límites de velocidad de una forma parecida
con extractos de ese documento. Con buen criterio (a mi juicio) Santiago ha
preguntado sobre la utilización de esos datos, pues en caso de conseguir
que sean de licencia aceptable por OSM tendríamos un conjunto de datos muy
especial: la TOTALIDAD de señales de tráfico de las carreteras dependientes
del estado. Un conjunto de datos inmenso, en los que los procesos de
debate, importación , conflación y revisión serán muy especiales (puesto
que como tales no hay señales de tráfico, más allá de algunas genéricas). Y
no os voy a esconder mi pasión por ellas. Se traduce en 29 presets y un
estilo para JOSM que soporta unos ocho mil códigos de 29 países diferentes.
No es que pegue autobombo, es que a nivel español es la única herramienta
que hay, tanto para verlas en JOSM, como para "ponerlas" o modificarlas con
el mismo programa (de cero y con el código se puede hacer de todo en OSM).

Es por eso que os pido ayuda. Entre los 300 y pico tipos del BOE y los 776
del excel nos queda todo un mundo de variedades, valores velocidades...Pero
aún así, ha habido algunos que no he sido capaz de descifrar, por ello os
pido ayuda. Y ya ha empezado a dar sus frutos.

En una carpeta de Drive (
https://drive.google.com/drive/folders/0B6EG7gFUQUDLeGhucnQwMkFIVjQ)
podreis encontrar una hoja de cálculo con los códigos de modelos que faltan
(que no he encontrado en wikipedia, vamos) , las instrucciones, y algunas
variaciones de modelos que he realizado yo, con Photoshop y otros
,vectoriales, que ha realizado Habiui. Si os aburrís y quereis ayudar a
descifrar los códigos que faltan os animo a que lo probeis.

¿Por qué esta petición antes incluso del debate y de la autorización
expresa para usar los datos? Porque esto es una parte de OSM que va a
llegar igualmente (si es que no lo ha hecho ya) de OSM.En la actualidad el
estilo para JOSM y el preset español son las únicas herramientas "manuales"
que tenemos para nuestro programa de edición favorito. Y es evidente que ,
si llega la aprobación, vamos a tener que estar preparados para aceptar
todas esas variaciones que no necesariamente salen en el BOE.

Además, esto puede tener otra consecuencia: que peticiones similares se
desarrollen en todas las administraciones  que tengan a su cargo vías con
señales.Así que agarraos que vienen curvas: 17 autonomías, 52 diputaciones
provinciales,más de 8000 ayuntamientos... Estas herramientas las vamos a
necesitar, al margen de que se autorice una importación en concreto o no,
al margen de que sea manual, semi o automático del todo, al margen de que
sea el Estado Español o sólo el ayuntamiento de Rabanillo de Arriba el que
nos dé permiso para manejar sus datos sobre señales de tráfico. Así que
estemos preparados.

¿Qué os parece todo el tema de importación de señales de tráfico, o su
misma inclusión en OSM?¿ Colaboraríais en un proceso así? ¿Qué esquema
creeis que se debe de seguir? Sugerencias, críticas, cuanto más se
participe y se observe la idea mejor.

Salut i senyals
yopaseopor

PD: github del preset beta ,el estable se puede bajar desde JOSM >
https://github.com/yopaseopor/beta_preset_josm/tree/master/ES
github del estilo beta, el estable se puede bajar desde JOSM >
https://github.com/yopaseopor/traffic_signs_style_JOSM
Taginfo sobre el proyecto:
https://taginfo.openstreetmap.org/projects/traffic_signs#tags
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Adresses...

[Christian Quest]

Le 18 janvier 2017 à 19:21, Jean-Martial NDOUTOUME NFENGONE - ZIT.COM <
jean-mart...@zitcom.fr> a écrit :

> Bonsoir,
>
> Merci, ça éclaire ma lanterne, et sur l'état de l'art de l'adressage en
> France, et sur l'état de l'art des adresses dans OSM.
>
> Ceci me fait comprendre pourquoi et comment certains numéros de rue ont
> été renseignés (ou pas) dans OSM:
> - avec la libération des données, on a pu importer les bâtis issus de
> la source cadastre-dgi-fr,
> - mais il n'y a pas de source officielle pour les adresses, donc les
> numéros de rues figurant dans OSM sont entièrement issus du travail
> collaboratif de la communauté.
>
> Est-ce bien ça?
>
>
Pas tout à fait.

Il n'y a pas eu de "libération des données" pour le cadastre. Nous avons le
feu vert de la DGFiP pour utiliser les données du cadastre que l'on ne peut
consulter gratuitement que via cadastre.gouv.fr. C'est la loi CADA de 78
qui de toute façon nous donne ce droit, il n'y a pas de régime de faveur en
fait.

Pour les adresses, on peut bien sûr les relever sur le terrain, mais elles
sont aussi visible sur les plans du cadastre et nous avons des scripts qui
comme pour le bâti permettent de les extraire automatiquement pour
faciliter leur intégration dans OSM.
On parle d'intégration (et pas d'import) car il faut fait de la
vérification manuelle avant d'envoyer ça vers OSM... et aussi en profiter
pour compléter les noms de rues manquantes, corriger les adresses qui ont
besoin de l'être (placement incohérent avec l'image aérienne par exemple).

Il y a aussi pas mal d'adresses dans OSM qui proviennent de données
opendata publiées par les collectivités. Mais là aussi, l'intégration est
préférable à l'import en aveugle.


> Pour le coup, de notre côté, dans notre métier au quotidien, nous sommes
> en mesure de contribuer massivement à cet enrichissement: nous avons besoin
> des adresses et les renseignons/mettons déjà à jour dans notre SI.
>
>
La BAN (et BANO) peuvent aider...



> Pour ce qui est de la «meilleure» façon de le faire, c'est donc en work in
> progress.
>
> Ceci étant dit, autant je vois le bâti sur OSM, mais je ne vois pas les
> parcelles?  Ont-elles déjà été importées?
>
>
Non, pas importées et le consensus est de ne pas les importer.

Pourquoi ?
1) ce n'est pas vérifiable sur le terrain
2) c'est beaucoup trop changeant... sans que ces changements soient
visibles sur le terrain
3) le volume est énorme (plus de 80 millions de parcelles, soit 4 fois plus
que les adresses)
4) ces données ne sont pas en opendata... il faudrait là aussi les extraire
depuis les plans sur cadastre.gouv.fr et leur calage est perfectible ce qui
pose plus de problème de raccord qu'un point adresse.
... j'arrête mais on peut trouver d'autres raisons ;)


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

Re: [OSRM-talk] hov_ways matching

[Daniel Patterson]

Mikey,

  ignore_hov_ways=true completely removes HOV-only roads from the routing graph 
- if the value is true, you won't match or route on HOV-only roads because they 
get dropped.

  Can you share your GPS trace?  If the matching result seems wrong, can you 
open a ticket at https://github.com/Project-OSRM/osrm-backend 
 please?

daniel

> On Jan 18, 2017, at 11:06 AM, Mikey Alexander 
>  wrote:
> 
> What does the ignore_hov_ways = false do, exactly?  I processed my maps with 
> this flag, expecting match to give routes on HOV ways
>  
> I’ve got sets of points that are clearly moving along 
> http://www.openstreetmap.org/way/141387707#map=15/38.5359/-77.3567 
> 
> The match algorithm matches it to one of the non-HOV segments of I-95.
>  
> Thanks,
> 
> Mikey
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/osrm-talk 
> 
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Jan Macura]

Ahoj,

2017-01-18 10:03 GMT+01:00 Karel Volný :

> obecně souhlas, akorát se neshodneme v tom, co je obsah a co je forma
>

Zalomení řádku je záležitost formy. Při každém zpracování textu může
dopadnout jinak (jinde). Obsah je na formátování řádek nezávislý. Takže
medle celá problematika "kde řádek zalomit" padá na hlavu zpracovatele dat.


> kontrolní dotaz - používání malých a velkých písmen je obsah nebo forma?
>

To záleží na kontextu. Obecně samozřejmě formy, ale v našem případě, tj.
sbírání a uchovávání místopisných názvů je extrémně výhodné, aby velikost
písmen byla přímo brána jako součást obsahu (neměnná). Neexistuje totiž
případ, kdy bychom ta slova uvažovali samostatně (slovo "libčice", slovo
"nad" a slovo "vltava") – OSM není ani výkladový slovník ani lexikografická
databáze.


>
> > Zalamování řádek, dělení slov, skloňování a časování ať je záležitostí
> > zpracování dat, ne jejich uložení.
>
> skutečně toto vše? - takže bychom vlastně neměli mít "Libčice nad Vltavou"
> ale
> "Libčice nad Vltava"? :-)
>
>
Heh, napsal jsem to moc obecně :-) Jasně, že v našem případě "Libčice nad
Vltavou", ale tahle diskuse ("zaveďme do slov nedělitelné mezery, protože
to ulehčí zpracování") by taky mohla vést k tomu, že zavedeme tagy
name:genitiv="Libčic
nad Vltavou", name:dativ="Libčicím nad Vltavou", atd. protože "routovací
enginy nabízejí uživateli i textový popis cesty a tohle jim ulehčí práci".
A to už bychom v OSM opravdu mít neměli ;-)

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

Re: [Talk-br] Mitula esta usando mapas do OSM sem dar créditos

[santamariense]

Só para atualizar a situação da Mitula não dar créditos ao OSM...
A Mitula não respondeu em um prazo de um mês. Assim, contatei a
Mapbox. A resposta foi:

Hi there,

Thanks! I'll reach out to this user. No further actions needed on your end.

best,

Angelina

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

[OSM-Talk-ZA] Orienteering

[Bernelle Verster]

Dear OSM community

This email relates to orienteering [1,2]. I am contacting you with the
general agenda to introduce you to what I think is an amazing sport
(amazing mainly because the intellectual navigational component takes
your mind off the bit about actually exercising), and the specific
agenda of growing our mapper community.

Fun fact: The OpenOrienteeringMap [3] is based on Open Street Maps!
(And I haven't figured out if the Open Orienteering [4] thing is
related to that or an independent project.)

Our next event is this Sunday, 22 January, in Bishopscourt, Cape Town.
More on our website [2].

The next few events after that:
12 Feb - Pagasvlei, Constantia
25 Feb - Zandvlei, near Muizenberg
26 March - UCT, Rondebosch

If this interests you, please check out our website [2] or our
facebook page [5] for more info or to stay in touch.

Hope to see you soon!
Bernelle
(indiebio)

[1] https://en.wikipedia.org/wiki/Orienteering
[2] http://penoc.org.za/
[3] http://oomap.co.uk/
[4] http://www.openorienteering.org/apps/mapper/
[5] https://www.facebook.com/peninsulaorienteeringclub

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

Re: [Talk-us] Green Mountain National Forest cleanup

[Kevin Kenny]

On Wed, Jan 18, 2017 at 9:58 AM, Jason Remillard 
wrote:

> hstore support, which would allow rendering boundary=protected_area is
> being actively worked on the main style sheet. Its coming...
>
> https://github.com/gravitystorm/openstreetmap-carto/issues/1504
> https://github.com/gravitystorm/openstreetmap-carto/issues/1975
>

I'm aware of those tickets. There are actually earlier related requests as
well, going back nearly five years. At this point I'm not holding my
breath. I'll be ecstatic if I see it actually happen, but at this point I
don't think I can plan for it.

The nice thing about the 'leisure=nature_reserve' tagging is that
correcting it can be automated easily. The 'boundary=national_park' tag
will require more manual work to reconcile, but is really the only tag we
can use for complex areas like the Adirondack Park or the GMNF without
telling worse lies to the renderer. (And, alas, it conflicts with
boundary=protected_area, so it isn't possible to tag the old and new
schemata simultaneously. boundary=national_park;protected_area will simply
cause more confusion.)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-pt] Importação massiva na Anadia

[Alexandre Moleiro]

Para mim o uso do solo tem que reflectir uma realidade concreta. Se decidir
ir dar um passeio de BTT espero poder confiar nos dados do OSM.
Assim, lá por uma área ser um loteamento industrial no PDM, se estiver
cheia de mato é isso que me vai interessar.

Alexandre

Em 18/01/2017 10:54, "Aurelio Pires"  escreveu:

> Olá a todos,
>
> Para mim, este email do Gustavo é uma boa síntese do que está em causa.
>
>  - Ocupação do solo: totalmente de acordo com a perspetiva apresentada.
>
>  - Usos do solo: também estou de acordo. E tendo em consideração este
> entendimento, tenho colocado em Braga as áreas industriais representadas no
> PDM colocando a tag source = PDM Braga 2015 [1]. Também me parece que são
> poucas as classificações que possam ter interesse para o OSM; talvez as
> zonas residenciais novas ou a expansão das existentes, e talvez as novas
> zonas comerciais e zonas verdes previstas. Mas acho que tem de se analisar
> caso a caso.
>
>  - Quanto às importações, tenho também o mesmo entendimento.
>
> Da discussão que sobre estes tópicos se fizer aqui na lista, sugiro que se
> faça uma síntese das conclusões para colocar no OSM wiki PT [2].
>
>  - Em relação ao primeiro SOTM-PT, acho que já começa a existir massa
> crítica suficiente e, por isso, acho que é oportuno fazê-lo; e desde já me
> disponibilizo para colaborar na organização.
>
>  - Quanto à importação de Anadia, sou da opinião que devia ser retirada!
>
> Abraço,
>
> APires
>
>
> [1] http://www.openstreetmap.org/way/259130983
> [2] http://wiki.openstreetmap.org/wiki/WikiProject_Portugal
>
>
>
> On 2017-01-18 0:12, Jorge Gustavo Rocha wrote:
>
>> Olá malta,
>>
>> Acho que temos que promover uma discussão entre nós em torno do que tem
>> interesse em termos de usos e ocupação do solo.
>>
>> Ocupação do solo (o que existe)
>>
>> De repente, acho que coisas como a Corine Land Cover não têm interesse
>> nenhum: é informação obsoleta, feita para estatísticas europeias, com
>> uma escala e um erro que não interessa (ao OSM). Qualquer um de nós
>> conseguiria fazer melhor de forma sistemática, hoje, usando dados do
>> Sentinel-2, sem sair do computador.
>>
>> Prefiro deveras que sejam os mapeadores a irem dizendo o que realmente
>> existe no terreno. Prefiro um mapa "menos" preenchido, mas "bem"
>> preenchido. O que está tem que estar bem.
>>
>> Quando exigimos que as importações têm que ser discutidas é para isso
>> mesmo: para entrarem dados bons, e não dados para depois serem corrigidos.
>>
>> Quando uma área, como Anadia, está toda preenchida, não sei o que está
>> bem e o que está mal. Infelizmente assumo que está tudo mal, mesmo que
>> um coitado de uma mapeador tenha já endireitado uma parte da importação.
>> Fica a dúvida sobre toda a área.
>>
>> Nestes casos de importação, também acontece que (sem querer) quem faz a
>> importação está a exigir aos outros mapeadores que corrijam e conciliem
>> o que foi importado com o que estão a mapear. Eu gosto de mapear onde e
>> quando me apetece e não gosto tanto de estar condicionado pelas
>> importações dos outros.
>>
>> Usos do solo (o que é permitido existir)
>>
>> Coisas relacionadas com usos do solo (regulamentação), determinados por
>> PDM de Câmaras e afins, poderão ter algum interesse, mas muito limitado.
>> É preciso ver que usos interessam. Sei que o geospot_mike (Águeda) tem
>> as áreas industriais (que me parece interessante), mas pouco mais
>> informação é relevante.
>>
>> Proposta para o primeiro SOTM-PT
>>
>> Acho que a necessidade deste tipo de discussão nos "obriga" a organizar
>> o primeiro SOTM-PT "oficial". Já tivemos grandes parties e algumas
>> oficinas de dados, mas acho que podemos fazer um SOTM com uma certa
>> dimensão. Se gostarem da ideia, ofereço-me para começar a tratar da
>> organização.
>>
>> Voltando a questão inicial dos usos e da ocupação do solo, gostava que
>> partilhassem a vossa opinião para depois tomar uma decisão. Estou
>> inclinado a pedir para retirarem a informação importada da Anadia.
>>
>> Abraço,
>>
>> J. Gustavo
>>
>> Às 23:19 de 17-01-2017, Rui Oliveira escreveu:
>>
>>> Acho que cabe ao Jorge decidir como deseja proceder sendo que foi ele
>>> que originalmente reportou a situação. Eu recebi a mensagem do
>>> utilizador referido e assim que a obtive coloquei aqui na lista, logo
>>> talvez o utilizador hhugboss tenha também respondido ao Jorge. Vamos
>>> esperar para ver o que ele diz.
>>>
>>> Cumprimentos
>>>
>>> 2017-01-17 18:25 GMT+00:00 Marcos Oliveira
>>> >:
>>>
>>>  Já se passou um mês, sempre é para deixar os dados no mapa?
>>>
>>>  No dia 15 de dezembro de 2016 às 11:48, Pedro Pereira
>>>  > escreveu:
>>>
>>>  Bom dia,
>>>
>>>  Uma vez que o Hugo refere "Sinceramente não percebo muito bem a
>>>  necessidade de discutir tal procedimento", sugiro que se
>>>  responda a 

[Talk-it] Mappa centri accoglienza terremoto l'Aquila

[Matteo Fortini]

Sto mappando i centri di accoglienza dalla lista fornita dal Comune 
dell'Aquila con l'aiuto di persone del posto che mi stanno dando le 
coordinate usando nominatim e la loro conoscenza.


Il livello di mappatura di alcuni centri è veramente ridotto, quando 
mancanti sto aggiungendo anche strade ed edifici in corrispondenza dei 
punti (foto Bing).


Esempio di nodo: http://www.openstreetmap.org/node/4616625471

Sto taggando come
amenitysocial_facility
social_facilityshelter
social_facility:fordisplaced

Tutti i gruppi di modifiche sono commentati con
#terremoto2017 #accoglienza #terremotocentroitalia

Se ci sono osservazioni o se qualcuno vuole dare una mano, grazie mille

Matteo

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

Re: [OSM-talk-fr] Adresses...

[Jean-Martial NDOUTOUME NFENGONE - ZIT.COM]

Bonsoir,

Merci, ça éclaire ma lanterne, et sur l'état de l'art de l'adressage en France, 
et sur l'état de l'art des adresses dans OSM.

Ceci me fait comprendre pourquoi et comment certains numéros de rue ont été 
renseignés (ou pas) dans OSM:
- avec la libération des données, on a pu importer les bâtis issus de la 
source cadastre-dgi-fr,
- mais il n'y a pas de source officielle pour les adresses, donc les 
numéros de rues figurant dans OSM sont entièrement issus du travail 
collaboratif de la communauté.

Est-ce bien ça?

Pour le coup, de notre côté, dans notre métier au quotidien, nous sommes en 
mesure de contribuer massivement à cet enrichissement: nous avons besoin des 
adresses et les renseignons/mettons déjà à jour dans notre SI.

Pour ce qui est de la «meilleure» façon de le faire, c'est donc en work in 
progress.

Ceci étant dit, autant je vois le bâti sur OSM, mais je ne vois pas les 
parcelles?  Ont-elles déjà été importées?

À vous lire

Jean-Martial


- Mail original -
> De: "Jérôme Seigneuret" 
> À: "Discussions sur OSM en français" 
> Envoyé: Mercredi 18 Janvier 2017 17:03:00
> Objet: Re: [OSM-talk-fr] Adresses...
> 
> 
> 
> 
> 
> Bonjour,
> 
> 
> 
> 
> En effet l'adressage marche comme un arbre. Suivant le niveau de
> finesse, l'adresse peut être déclinée sur beaucoup d'objet de type
> variable.
> 
> 
> 
> Les entrées, les portails, les bâtiments, sont des informations
> importantes. Le schéma n'est pas trivial! Et les besoins pour
> accéder à une adresse ne l'est pas non plus
> 
> 
> 
> 
> 
> * le schéma le plus simple est le placer l'adresse au portail
> (mais il peut y en avoir plusieurs
> * l e deuxième au bâtiment
> * le troisième à l'entrée
> * le 4ème dans le tronçon de voirie ou rapporté au tronçon
> * et il y en a d'autre.
> 
> 
> 
> 
> 
> 
> Les besoins de précision ne sont pas les même pour tout le monde. Il
> serait même utile d'avoir des doubles infos avec l'adresse au point
> d'accès et l'accès au point de livraison.
> 
> C'est la notion aussi des cedex pour les pros. Il y a l'adresse
> d'accès et l'adresse courrier. Il me semble que cette notion a été
> abordé lors des discutions sur l'usage de contact:housenumber
> 
> 
> 
> Si l'on prend une logique purement spatiale sans avoir à répéter
> l'adresse sur des objets, cette adresse devrait être soit sur un
> polygone soit sur une relation.
> 
> 
> 
> L'adressage est un élément complexe désignant un ensemble d'éléments.
> D'où cette discussion sans fin avec des cas toujours plus farfelus.
> (Sans compter que certaines villes ce sont mises à vouloir faire de
> l'adressage pour les éléments public de la ville > devenu inutile
> avec les GPS et algo de rapprochement)
> 
> 
> 
> 
> 
> La notion de parcelle dans le document m'inquiète car la parcelle
> peut être à cheval pour plusieurs bâtiments, numéro d'adresse etc.
> Dans ce cas c'est un découpage particulier qui est cohérent comme
> celui des code postaux (hors Cedex car c'est sur le site de tri
> postal), celui des villes et les rues. Bonjour la finesse des
> données... Donc pour moi une parcelle postale ne doit exister que si
> un point n'est pas suffisant pour définir une adresse. C'est le cas
> pour certains niveau comme pour les ZA etc les Résidences et
> d'autres à lister.
> 
> 
> 
> Si l'on part du principe parcellaire qui évolue... l'adressage
> évoluera en parallèle dans 90% des cas. Surtout si l'adressage est
> métrique (déplacement d'entrée = nouveau numéro)
> 
> 
> 
> Arf! Je vois rue sans adresse et un 9... C'est de la gestion de
> base à papa! Soit on ne mais rien 'NULL' soit on ajoute un élément
> permettant de définir l’inexistence réel d'information mais pas une
> valeur aberrante. Bref l’inexistence est une valeur en soit. Sinon
> il vaut mieux mettre un commentaire exploitable et normalisé.
> 
> 
> 
> Le “15 rue des Mimosas” montre bien l'exemple dans l'adressage
> multiple même si actuellement Osmose retourne des alertes pour
> l'ensemble à cas de multiplicité.
> 
> 
> 
> Coté date de mise à jour... ça dépends aussi dans quel sens la mise à
> jour est effectuée. Dans ce cas il manque aussi la source de la mise
> à jour et le créateur initiale pour comparaison.
> 
> 
> 
> Il faut intégrer plus de cas dans ce document. Ces cas sont assez
> valable pour des particuliers mais un peu moins sur des pro ou sur
> des ZI ZA ... de lieu-dit car ils sont tagués au format point dans
> beaucoup trop de cas.
> 
> À noter que certaines ZI n'ont pas de nom de rue ni de numéro de
> voie.
> 
> Quant au zonage réel des ZI ou ZAC, si l'on se base sur le landuse on
> se retrouve sur des problématiques de découpages à causes des
> activités humaines de la dite zones. En clair le nom est plus lié à
> un découpage du même type que les parcs et les communes ce qui
> permettrait également de les exploiter dans l'adressage.
> 
> 
> 
> Coté lieu-dit, les voies sont dans certains 

Re: [OSM-talk-fr] Adresses...

[Jérôme Seigneuret]

Bonjour,


En effet l'adressage marche comme un arbre. Suivant le niveau de finesse,
l'adresse peut être déclinée sur beaucoup d'objet de type variable.



Les entrées, les portails, les bâtiments, sont des informations
importantes. Le schéma n'est pas trivial! Et les besoins pour accéder à une
adresse ne l'est pas non plus




   - le schéma le plus simple est le placer l'adresse au portail (mais il
   peut y en avoir plusieurs
   - le deuxième au bâtiment
   - le troisième à l'entrée
   - le 4ème dans le tronçon de voirie ou rapporté au tronçon
   - et il y en a d'autre.



Les besoins de précision ne sont pas les même pour tout le monde. Il serait
même utile d'avoir des doubles infos avec l'adresse au point d'accès et
l'accès au point de livraison.

C'est la notion aussi des cedex pour les pros. Il y a l'adresse d'accès et
l'adresse courrier. Il me semble que cette notion a été abordé lors des
discutions sur l'usage de contact:housenumber



Si l'on prend une logique purement spatiale sans avoir à répéter l'adresse
sur des objets, cette adresse devrait être soit sur un polygone soit sur
une relation.



L'adressage est un élément complexe désignant un ensemble d'éléments. D'où
cette discussion sans fin avec des cas toujours plus farfelus. (Sans
compter que certaines villes ce sont mises à vouloir faire de l'adressage
pour les éléments public de la ville > devenu inutile avec les GPS et algo
de rapprochement)





La notion de parcelle dans le document m'inquiète car la parcelle peut être
à cheval pour plusieurs bâtiments, numéro d'adresse etc. Dans ce cas c'est
un découpage particulier qui est cohérent comme celui des code postaux
(hors Cedex car c'est sur le site de tri postal), celui des villes et les
rues. Bonjour la finesse des données... Donc pour moi une parcelle postale
ne doit exister que si un point n'est pas suffisant pour définir une
adresse. C'est le cas pour certains niveau comme pour les ZA etc les
Résidences et d'autres à lister.



Si l'on part du principe parcellaire qui évolue... l'adressage évoluera en
parallèle dans 90% des cas. Surtout si l'adressage est métrique
(déplacement d'entrée = nouveau numéro)



Arf! Je vois rue sans adresse et un 9... C'est de la gestion de base à
papa! Soit on ne mais rien 'NULL' soit on ajoute un élément permettant de
définir l’inexistence réel d'information mais pas une valeur aberrante.
Bref l’inexistence est une valeur en soit. Sinon il vaut mieux mettre un
commentaire exploitable et normalisé.



Le “15 rue des Mimosas” montre bien l'exemple dans l'adressage multiple
même si actuellement Osmose retourne des alertes pour l'ensemble à cas de
multiplicité.



Coté date de mise à jour... ça dépends aussi dans quel sens la mise à jour
est effectuée. Dans ce cas il manque aussi la source de la mise à jour et
le créateur initiale pour comparaison.



Il faut intégrer plus de cas dans ce document. Ces cas sont assez valable
pour des particuliers mais un peu moins sur des pro ou sur des ZI ZA ... de
lieu-dit car ils sont tagués au format point dans beaucoup trop de cas.

À noter que certaines ZI n'ont pas de nom de rue ni de numéro de voie.

Quant au zonage réel des ZI ou ZAC, si l'on se base sur le landuse on se
retrouve sur des problématiques de découpages à causes des activités
humaines de la dite zones. En clair le nom est plus lié à un découpage du
même type que les parcs et les communes ce qui permettrait également de les
exploiter dans l'adressage.



Coté lieu-dit, les voies sont dans certains systèmes une partie intégrante
du nom du linéaire. Cela simplifie le routing. Ce n'est pas le cas dans OSM
et c'est la même chose pour le nom des résidences.

Les résidences sont nommées de manière variable (au bâtiment, au landuse,
sur un place et parfois réellement sur la voie car la commune a mis un
panneau de voirie pour la résidence)



Cordialement,

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

Re: [Talk-it] information=guidepost vs sign vs altro, quale meglio?

[girarsi_liste]

Il 18/01/2017 14:17, Martin Koppenhoefer ha scritto:
> 2017-01-17 19:40 GMT+01:00 girarsi_liste :
> 
>> Per il momento ho taggato con:
>>
>> tourism=information
>>
>> information=guidepost
>>
>> inscription=B nome
>>
>>
>> Però pnso vada meglio al posto di guidepost, sign, perchè di fatto è un
>> segnale/informazione sul posto e c'è solo quello che io sappia, non ne
>> ho visti altri in quel paese.
>>
> 
> 
> è forse discutibile, ma per me sarebbe più appropriato il tagging
> "advertising" anzichè "information":
> 
> https://wiki.openstreetmap.org/wiki/Advertising
> 

Questo mi sembra appropriato, magari alcuni tag proposti insieme sono di
troppo, ma la tabella è funzionale a questa descrizione, grazie.

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



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

Re: [Talk-us] Green Mountain National Forest cleanup

[Jason Remillard]

Hi Kevin,

hstore support, which would allow rendering boundary=protected_area is
being actively worked on the main style sheet. Its coming...

https://github.com/gravitystorm/openstreetmap-carto/issues/1504
https://github.com/gravitystorm/openstreetmap-carto/issues/1975

Otherwise, I agree with your logic on tagging.

Jason


On Tue, Jan 17, 2017 at 3:38 PM, Kevin Kenny 
wrote:

> My big issue with this is that we - alas! - need to have something "tagged
> for the renderer."
>
> Over on the other side of Lake Champlain and the Taconics, we have the
> same problem with the Catskill and Adirondack Parks, which are protected
> areas with an immense public-private partnership. (Something over half the
> Adirondack Park is owned by New York State, and the rest is quite
> restrictively administered by the Adirondack Park Agency. Its level of
> protection exceeds that of any of our National Parks.)
>
> The problem is that boundary=protected_area does not render in any of the
> map layers available from openstreetmap.org. People editing
> protected_area's cannot see their results on the server, and newcomers to
> OSM don't even know that we have them in the database.
>
> I'd say that the answer is, "fix the renderer" - and surely
> Mapnik/Carto/... can handle it, since I use that toolchain to render my own
> maps. The underlying issue is that to fix it in any of the default
> renderings (OSM default, OpenCycleMap, etc.), 'hstore' would have to be
> enabled on the server's database to get the 'protect_class' tag into the
> system. For whatever reason, the server team has balked at doing this for
> quite literally several years. I do not expect this situation to resolve in
> my lifetime,. and I have ceased to request any support for protected area
> rendering. Instead, I do most of my own rendering on maps such as
> http://kbk.is-a-geek.net/catskills/test3.html, and accept the fact that I
> will have a day or two delay in being able to retrieve any updates. (I
> don't have the resources to accept minutely updates, so I depend on the
> daily extracts at geofabrik.de. Often, I let my map fall several months
> behind, when I'm not actively mapping).
>
> Most US mappers have simply accepted that the renderer will not be fixed.
> The compromise that I used when reworking the Adirondack Park polygons was
> not well received on this list, but at least nobody reverted the changes.
> In that compromise solution:
>
> - the Adirondack and Catskill Parks as a whole were tagged
> boundary=national_park. This tagging is close to the truth except that it
> is New York State rather than a nation-state that administers it. Given the
> US principle of separate sovereignty, I'm willing to live with this.
>
> - the individual state (and in the case of the Catskills, New York City)
> owned parcels received the additional tagging of 'leisure=nature_reserve'
> plus appropriate 'protected_area' tagging. That way, they are correct in
> the new scheme and still render plausibly. 'Nature reserves' encompass many
> different things, so I wasn't too uncomfortable with this tagging.
>
> - I seriously attempted to make appropriate choices for 'protect_class'
> and related tags. This sometimes meant up-classifying relative to the IUCN
> database. IUCN wants to classify the Adirondack and Catskill holdings no
> higher than protect_class=6, because they don't enjoy national-level
> protection. That's again a failure to understand the US legal system; the
> State-level protection that they enjoy is far stronger than any Federal
> protection: these two parks are read into the state constitution. I was
> entirely comfortable giving the High Peaks or West Canada Lake wilderness
> areas protect_class=1b. They are indeed protected wilderness, where Man is
> a visitor who does not remain.
>
> The result of the compromise is, as you can see:
>
> - everything renders on the main page. The parks are at least visible.
> (There has been at least one round with the National Forests that rendered
> them entirely invisible.)
>
> - the 'landuse=forest' tag is not abused. There is no green infill on
> tracts that are not forested. The system still presumes that
> 'landuse=forest' means 'every square metre covered by trees - and cannot
> cope with the idea of 'the landowner's intent is to use the tract for
> forestry, but this particular bit, this year, is occupied by beavers' -
> according to the OSM purists, that's no longer 'forest'. (For this reason,
> I find 'landuse=forest' to be nearly useless: all the 'forest' tracts that
> I've ever mapped have transient or permanent phenomena meaning that
> individual pieces may be clearcut, bare rock, or open water at a particular
> time.)
>
> - the 'leisure=nature_reserve' tag is only slightly abused. A wilderness
> area, a wildlife management region, or a protected watershed (all of which
> permit recreational use) are all reserved to nature, and no US English
> speaker would be astonished 

Re: [Talk-ca] [Talk-us] cardinal directions

[Martijn van Exel]

I am trying to be consistent with the outcome of the discussion that we had on 
talk-us a couple of years ago. Right now both are used (north/south/east/west 
as relation member role as well as direction on the relation tag) but the 
former is used way more often. That’s why I am suggesting going with the 
practice that has surfaced as the most popular, as well as the outcome of 
earlier discussion. 

Perhaps I am not understanding you correctly, but I am *not* suggesting to use 
tags on ways to indicate cardinal direction, just assign roles to relation 
members. Agreed that adding this type of info to ways makes it impossible to 
validate / maintain.

This also does not have to preclude having separate e/w or n/s relations + a 
super relation — I think that is actually good practice for big relations to 
keep them manageable.

Martijn van Exel

> On Jan 13, 2017, at 11:40 PM, Paul Johnson  wrote:
> 
> 
> 
> On Fri, Jan 13, 2017 at 3:42 PM, Martijn van Exel  > wrote:
> Hi all, 
> 
> Some of you may remember the discussion we had on tagging cardinal directions 
> in the US, which led to the wiki page[1] describing the current practice.
> Basically the convention we arrived on is to tag relation members with 
> role=north/east/south/west to indicate cardinal direction.
> This is backed up by usage in the US. About 75% of way members of Interstate 
> road relations have directional role members[2].
> 
> Can we not do this?  Can this not be a thing?  Can we instead go route master 
> and only have child relations have cardinal roles, with child ways being 
> exclusively forward/backward?  Because cardinal directions on the ways 
> themselves is 1) ambiguous AF and 2) breaks validation on a level that it can 
> take hours to days for experienced editors to manually validate, and can't be 
> automated as a result.
> 
> ___
> Talk-us mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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

Re: [Talk-GB] Named landuse polygons

[Dan S]

2017-01-18 13:51 GMT+00:00 Dave F :
> Hi
>
> Do people reside & sleep in the park or nursery?
> If 'no' then is it really residential?

...!

> http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dresidential
>
> As the database becomes more detailed/accurate the "granularity" gets
> smaller. Entities like 'residential' will have less blanket coverage, items
> will be individually tagged Which is what you note in another of your posts:
> "And the address of the nursery also includes "Queen's Park Court": "
> So the cover-all named residential area becomes redundant.

If you're aiming to remove the redundancy from OSM... good luck ;)

It makes perfect sense to me that there can be an identifiable area
whose name is "Queen's Park Court" and also that "Queen's Park Court"
would be a part of the address for some item within it.

Cheers
Dan



> Regarding the nursery I'd redraw the residential around it, map it's
> boundary fence as amenity=kindergarten, transfer all the address data to
> that polygon & tag the building with building=kindergarten. This is how the
> vast majority of the schools were tagged in the recent GB quarterly project.
>
> Cheers
> DaveF
>
> On 18/01/2017 11:24, Derick Rethans wrote:
>>
>> It's part of the residential estate, so I disagree with that. cheers,
>> Derick
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-it] OSMit2017 a Genova 8-11 febbraio in FOSS4G

[Alessandro]

Salve lista,

Sono stati superati i 100 iscritti. Voi vi siete già registrati qui? 
https://goo.gl/forms/nhi7es1SNrUpdPC62


Per chi si ferma più giorni abbiamo sistemazioni a partire da 16€ in 
camerata. A breve la lista completa delle strutture selezionate.


http://www.dicca.unige.it/geomatica/foss4git_2017/

Occorre registrarsi anche ai workshop di mercoledì 8, quasi tutti ad 
Architettura tranne 'Costruire un sistema di monitoraggio ambientale 
aperto'. Nel form di registrazione troverete l'indicazione degli 
eventuali workshop ai quali vorrete iscriversi.
E' in corso l'accreditamento all'Ordine degli Architetti dei workshop 
per ottenere dei crediti formativi!


Sabato è confermato il mapping party a Santa Margherita Ligure che ha 
tanto bisogno di una mappatura amorevole. Oltre al centro di Santa anche 
la vicina San Michele di Pagana ha tanto bisogno :-)

Oltre a mappatura OSM sarà possibile editare articoli Wikipedia.

Giovedì sera ricordo la serata social nell'incantevole ambientazione del 
Castello D'Albertis. Venerdì sera serata informale con aperitivo nel 
centro storico e cena in qualche trattoria Zeneise.


Alessandro Ale_Zena_IT

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

Re: [Talk-lt] Asociacija „Atvirasis žemėlapis“

[Mykolas Okulič-Kazarinas]

Sveiki, OSM aktyvistai.

AKL vardu - ačiū už šiltą žodį.

Bendruomenė visada palaikė ne tik atvirąsias programas,
bet ir atviruosius duomenis (OSM, Vikipediją, COD ir kt.).
Ne vienas AKL aktyvistas dalyvauja šiame forume ir OSM veikloje.

Manau, galėtume teigti, kad nuo 2009 metų veikęs
AKL OpenStreetMap komitetas (pirmininkas Tomas Straupis)
yra reorganizuojamas į asociaciją „Atvirasis žemėlapis“.

Taigi, asociacijos „Atvirasis žemėlapis“ pradžia
buvo 2008 m., kai sukurtas šis forumas
arba 2009 m., kai sukurtas AKL komitetas.


2017 m. sausio 17 d. 22:25, Tomas Straupis  rašė:
> Sveiki
>
>   Įkurta asociacija „Atvirasis žemėlapis“.
>   Bendrą informacija kaip/kur/kas rasite dienoraštyje:
>   https://blog.openmap.lt/2017/01/17/asociacija-atvirasis-zemelapis/
>
> --
> Tomas
>
> ___
> Talk-lt mailing list
> Talk-lt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lt



-- 
Mykolas Okulič-Kazarinas

+370 6985 1144

Sent frоm my Mozilla Firefox

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

Re: [Talk-it-trentino] [Linuxtrent] Re: Sportello Open

[Cristian Cenci]

Siamo usciti anche su La Voce del Nordest:
http://www.lavocedelnordest.eu/in-trentino-parte-lo-sportello-open-delle-comunita-linux-openstreetmap-e-wikipedia/

Cristian


Il 18.01.2017 10:34, Marco Ciampa ha scritto:
> On Tue, Jan 17, 2017 at 05:09:25PM +0100, Marco Ciampa wrote:
>> On Tue, Jan 17, 2017 at 05:01:32PM +0100, Luca Delucchi wrote:
>>> Ciao a tutti,
>>>
>>> volevo segnalare che Venerdì a Pergine si terrà il primo Sportello Open.
>>>
>>> Lo Sportello Open è l'ex sportello Linux di Pergine che si amplia e
>>> aggiunge altre 2 attività, OpenStreetMap e Wikimedia.
>>>
>>> L'appuntamento è presso la sede della Sat di Pergine ore 20.30.
>> Ecco un articolo in proposito:
>>
>> https://www.cultura.trentino.it/Approfondimenti/In-Trentino-parte-lo-Sportello-Open-delle-comunita-Linux-OpenStreetMap-e-Wikipedia
>>
>> Con preghiera di diffusione...
>>
> Lo stesso articolo sul sito di wikimedia:
>
> http://www.wikimedia.it/vuoi-saperne-piu-linux-openstreetmap-wikipedia-chiedilo-allo-sportello-open/
>

-- 
Cristian Cenci
Project manager Wiki Loves Monuments Italia
Coordinatore regionale per il Trentino-Alto Adige | Regionalkoordinator
für Trentino-Südtirol
Wikimedia Italia – Associazione per la diffusione della conoscenza libera
Tel. +39 393 8005889 | cristian.ce...@wikimedia.it | www.wikimedia.it
___
Talk-it-trentino mailing list
Talk-it-trentino@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-trentino

Re: [Talk-GB] Named landuse polygons

[Dave F]

I agree & it's previously been pointed out that contributors are using 
OS opendata streetview, but I don't think it's correct usage of the tag.


isolated farms (I presume you mean farmyards) should be mapped as 
polygons & tag with landuse=farmyard.

Whole farms, including fields, should be landuse=farmland

Cheers
DaveF

On 18/01/2017 13:20, Andrew Hain wrote:


OSM is influenced by the maps its contributors see and are used to. In 
Britain that includes names of isolated farms on Ordnance Survey maps.




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Named landuse polygons

[Dave F]

Hi

Do people reside & sleep in the park or nursery?
If 'no' then is it really residential?

http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dresidential

As the database becomes more detailed/accurate the "granularity" gets 
smaller. Entities like 'residential' will have less blanket coverage, 
items will be individually tagged Which is what you note in another of 
your posts:

"And the address of the nursery also includes "Queen's Park Court": "
So the cover-all named residential area becomes redundant.

Regarding the nursery I'd redraw the residential around it, map it's 
boundary fence as amenity=kindergarten, transfer all the address data to 
that polygon & tag the building with building=kindergarten. This is how 
the vast majority of the schools were tagged in the recent GB quarterly 
project.


Cheers
DaveF

On 18/01/2017 11:24, Derick Rethans wrote:
It's part of the residential estate, so I disagree with that. cheers, 
Derick 



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Talk-GB] Named landuse polygons

[Andrew Hain]

OSM is influenced by the maps its contributors see and are used to. In Britain 
that includes names of isolated farms on Ordnance Survey maps.

--
Andrew

From: Dave F 
Sent: 17 January 2017 23:00:37
To: talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] Named landuse polygons

Please be aware this is the talk-GB forum.

Use of place=farm in Britain is almost certainly misguided. If anyone
knows of an appropriate location please post here.

It's not use of the tag itself that's the problem, it's contributor's
misinterpretation of it.

DaveF


On 17/01/2017 21:52, Warin wrote:
> On 18-Jan-17 07:27 AM, Dave F wrote:
>>
>> On 17/01/2017 19:38, Warin wrote:
>>
>>> Generally I add a node place=farm as I am not certain where the
>>> boundary lies
>>
>> This is a misuse of this tag. place=farm is for the rare (non
>> existent?) cases where a residential community, such as a hamlet, has
>> acquired the name of an adjacent farm. "a place named by a name of a
>> farm" - http://wiki.openstreetmap.org/wiki/Farm
>>
>> The description for
>> http://wiki.openstreetmap.org/wiki/Tag:place%3Dfarm is poorly written
>> & confusing.
>>
>> If mapping just the sheds/farmhouse etc of a farm, landuse=farmyard
>> should be used.
>>
>> It was discussed previously:
>> https://lists.openstreetmap.org/pipermail/talk-gb/2016-September/019181.html
>>
>>
>> DaveF
>
> In Australia .. place=farm is appropriate.
> The next farm may be 250 miles away, as such it usually has facilities
> for seasonal workers (say 20 people), machinery maintenance, air
> strip, ... etc.
> They are substantial places that are important in a mapping and social
> sense.
> Most still have the name painted on the roof to assist aerial navigation.
>
> Remember that OSM is world wide, you can define things locally .. but
> they won't fit everywhere, hence the OSMwiki fuzziness.
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Talk-it] information=guidepost vs sign vs altro, quale meglio?

[Martin Koppenhoefer]

2017-01-17 19:40 GMT+01:00 girarsi_liste :

> Per il momento ho taggato con:
>
> tourism=information
>
> information=guidepost
>
> inscription=B nome
>
>
> Però pnso vada meglio al posto di guidepost, sign, perchè di fatto è un
> segnale/informazione sul posto e c'è solo quello che io sappia, non ne
> ho visti altri in quel paese.
>


è forse discutibile, ma per me sarebbe più appropriato il tagging
"advertising" anzichè "information":

https://wiki.openstreetmap.org/wiki/Advertising

A prescindere, personalmente per i guidepost non aggiungo più
"tourism=information", ma soltanto information=guidepost. Forse non è
secondo lo standard, ma trovo che tourism=information spesso viene
interpretato male (senza guardare le sottochiavi), e in realtà
information=guidepost non dice meno che la combinazione con
tourism=information.

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

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Petr Kadlec]

Ahoj,

souhlas třeba s Kavolem. Do názvu Nová Ves u Chýnova nezlomitelná mezera
patří, proto tam má být i v OSM. Do názvu Týnec nad Sázavou nezlomitelná
mezera nepatří, proto tam nemá být ani v OSM. Nemá to nic společného s
renderery a správným vykreslováním, ale prostě s tím, že se to tak má psát
(stejně jako diakritika, pomlčka pomlčkou, spojovník spojovníkem atd.).
Jestli nějaký renderer, editor, uživatel nezná/neumí Unicode, tak holt
občas nebude dokonale fungovat. A holt taky občas nějaký uživatel něco
zadá/upraví bez té mezery, stejně jako existují uživatelé, kteří (k mému
úžasu) do OSM zadávají názvy bez diakritiky.

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

Re: [OSM-talk-fr] Adresses...

[osm . sanspourriel]

Dans https://drive.google.com/file/d/0B3TzG4CYNDnYSXM0dDhaVjNGTDQ/view 
il n'est question que de bis/ter... et a/b/c (éventuellement a_a)


Si dans le schéma Bano tu ne peux mettre Immeuble Sigma, porte A je vois 
mal comment le schéma OSM pourra marcher.


40 Sigma A ça n'entre pas dans le schéma.

> Reste à connaitre ce lettrage pour l'ajouter aux noeuds !

C''est déjà la cas des bâtiments nommés (Sigma).

Pour les autres c'est souvent une entreprise : Hôtel Mercure, le postier 
sait trouver.


Pour les relevés d'eau, non c'est une armoire technique au niveau du 
trottoir 
 
: VéOLia a les numéros de compteurs et les noms des abonnés (il y a sans 
doute une autre armoire pour l'autre entrée).


Pareil je suppose pour l'électricité (gaines techniques).

Oui il faudrait ajouter des noms plus complets mais quand le modèle ne 
propose pas vraiment de les mettre (sauf à créer des noms de rue ce qui 
serait simple et logique).


12 bâtiments au 40, comme je dis à côté des Parisiens, les Rennais font 
petits joueurs et c'est heureux :


http://www.openstreetmap.org/search?query=40%2C%20rue%20du%20bignon%2C%20cesson-s%C3%A9vign%C3%A9#map=18/48.09900/-1.61655

N. B. : je pensais que certains bâtiments avaient leur nom (Alpha, 
Sigma, Omega...) sur OSM.


Jean-Yvon

Le 17/01/2017 à 23:29, Philippe Verdy - verd...@wanadoo.fr a écrit :
Pour ça le schéma proposé indique d'ajouter des suffixes aux numéros, 
autrement dit les numéros/lettres de porte/bâtiment, même si ce sont 
des numéros attribués au départ par une partie privée des 
(co)propriétaire(s). Voilà qui dédoublonnerait le 40 rue du Bignon.
Reste à connaitre ce lettrage pour l'ajouter aux noeuds ! Cette info 
doit bien exister quelque part ne serait-ce que pour la poste ou 
l'administration fiscale qui ne se contente pas de taxer le 
propriétaire de la parcelle, mais aussi chacun des résidents (et a 
donc besoin d'adresses plus précises !), et les services de secours 
qui eux aussi ont besoin d'indications. Les relevés de compteurs d'eau 
et d'électricité aussi... Alors peu importe si le lettrage des numéros 
de la commune ou pas. Et nombre de copropriétés sont régulièrement 
redivisées et sont amenées à avoir des adresses distinctes.


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

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Jan Martinec]

Takže "hrůza z bílých znaků, protože Word je přesně jako OSM db"? ;) Na
rozdíl od Wordu je celá OSM infrastruktura na Unicode, tohle je argument
"předtím to tak nebylo, nový špatný." Stejnou logikou bychom vlastně měli
používat jenom ASCII - já sám mám hromadu strašidelných historek o Wordu a
diakritice.

HPM



Dne 18. 1. 2017 12:17 odp. napsal uživatel "Mikoláš Štrajt" <
stra...@seznam.cz>:

> Zdar,
>
> vzhledem k tomu, že jsem taky autor rendereru (https://github.com/severak/
> lunarender), dodal bych rád svůj pohled na věc:
>
> Do dat bych nezalomitelnou mezeru (dále jen NBSP) raději nedával. Dovedu
> si hodně živě představit, že s NBSP něco (renderer, geokóder, editor) co
> zpracovává OSM data nepočítá a výsledkem budou nějaké bizarní chyby, které
> navíc nebude jednoduché odhalit, protože NBSP se zobrazuje jako bílý znak.
>
> Dokonce mě překvapilo, že se vůbec zalamují dlouhé názvy. :-)
>
> Bílé znaky jsou v tomhle celkem svinstvo, pamatuju si jak u nás ve firmě
> přestaly fungovat jakési XML exporty, protože do dat klienti kopírovaly
> (netisknutelné) řídící znaky z Wordu. Vtip byl v tom, že některé bílé znaky
> nejsou validní v XML.
>
> -- Mikoláš Štrajt / Severák / http://severak.svita.cz/
>
> PS: můj renderer "vykresluje" celé názvy na jednom řádku
>
> -- Původní zpráva --
> Od: LukášKaras 
> Komu: talk-cz@openstreetmap.org
> Datum: 17. 1. 2017 8:47:10
> Předmět: [Talk-cz] Nedělitelná mezera v OSM datech
>
> Ahoj, o víkendu autor OSM Scout knihovny přidal užitečnou funkcionalitu
> - zalamování dlouhých popisků do více řádků. Dle očekávání se ale názvy
> zalamují v místech kde vykreslovací engine uzná za vhodné, nikoliv tam kde
> je to správně (předložky zůstávají na konci řádku), například:
>
> Libčice nad
> Vltavou
>
> Týnec nad
> Sázavou
>
> Tam lze "nad" na konci řádku ještě tolerovat i když mě osobně se nelibí,
> ale u "u":
>
> Nová ves u
> Chýnova
>
> Je to typograficky špatně. Stejným neduhem trpí i Mapnik.
>
> Moje otázka zní, zda-li je žádoucí do OSM přidávat na taková místa
> nedělitelné
> mezery (v xml "", unicode znak U+00A0) a existuje na to nějaký
> postup
> jak to provést hromadně? Poradí si s tím běžné editory? Neztratí se ta
> mezera
> při první editaci?
>
> Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba
> opravit
> renderer, ale bez ní nemá prostě šanci cokoliv hádat...
>
> Lukáš
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-GB] Named landuse polygons

[Derick Rethans]

On Tue, 17 Jan 2017, Paul Sladen wrote:

> On Tue, 17 Jan 2017, Dave F wrote:
> > On 17/01/2017 14:32, Derick Rethans wrote:
> > > http://www.openstreetmap.org/way/77260547
> >
> > I think this is inaccurate mapping. The buildings are called 'Queen's 
> > Park Court' The residential area should not include the grassed area or 
> > the nursery.
> 
> Residental areas normally are mapped so that they include the gardens
> belonging to the residences.  If the 'green space' is the 'gardens'
> for the surrounding tower blocks this is perhaps correct?

That is indeed the case.

> A solution might be to ask whether somebody living in Queen's Park
> Court would count the garden in the middle as being part of QPC?
> 
> For the nursery, it's could be less clear cut:  eg. is the nursey
> perhaps on the ground floor with housing above?

It is, sortof. The maps / signs around the estate do include the nursery 
and grassy area. And the address of the nursery also includes "Queen's 
Park Court": 
https://www.leyf.org.uk/find-a-nursery/westminster/katharine-bruce-community-nursery/#testimonials

Funnily, Google Maps gets both the location and the Street Names wrong 
in the area (the estate is on Ilbert Street, and not Droop Street).
https://www.google.co.uk/maps/place/Katharine+Bruce+Community+Nursery/@51.5286397,-0.2150088,18z/data=!4m13!1m7!3m6!1s0x4876101629deff45:0x44043504afa2d948!2sDroop+St,+London+W10!3b1!8m2!3d51.5276284!4d-0.2119691!3m4!1s0x0:0x9668261a517ad8fd!8m2!3d51.5291225!4d-0.2141281?hl=en

There are more estates in the area, but I have not mapped them yet as 
such. For example:

http://www.openstreetmap.org/way/77260547#map=18/51.52966/-0.20654=G


cheers,
Derick

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

Re: [OSM-talk-fr] Centrales électriques

[osm . sanspourriel]

Il me semble raisonnable de faire l'hypothèse que yes=le plus petit.

Car il vaut mieux afficher que ne pas afficher et les petits équipements 
sont ceux les moins facilement renseignables.


Un truc trop petit, tu veux le préciser si tu connais alors qu'un truc 
carrément absent...


Peut-être avec une couleur estompée pour montrer que ce n'est pas une 
puissance connue ?


Jean-Yvon

Le 18/01/2017 à 00:26, Jérôme Amagat - jerome.ama...@gmail.com a écrit :
Le problème c'est que j'affiche que s'il y a une valeur pour 
plant:output:electricity=*. là il y a yes et pas la puissance en 
watts. sinon avec yes impossible de savoir si c'est une énorme 
centrale ou un petit panneau solaire et donc comment l'affiché au 
milieu des autres qui ont une taille proportionnelle à leur puissance?.



Bonne soirée

Adrien



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

Re: [Talk-GB] Named landuse polygons

[Derick Rethans]

On Tue, 17 Jan 2017, Dave F wrote:

> 
> On 17/01/2017 14:32, Derick Rethans wrote:
> > 
> > It is what I do too:
> > http://www.openstreetmap.org/way/77260547
> 
> I think this is inaccurate mapping. The buildings are called 'Queen's Park
> Court' The residential area should not include the grassed area or the
> nursery.

It's part of the residential estate, so I disagree with that.

cheers,
Derick

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

Re: [OSM-talk-be] Next BXL meeting date? Date du prochain meeting a BXL?

[Bessières , Marc]

No problem, I've just extended the poll by one week to the beginning of
March 

Le 2017-01-18 11:32, joost schouppe a écrit :

> Well yes, I was also thinking it was about time to have another Antwerp 
> Meetup. Maybe we can push this Brussels one a bit back to the end of February 
> and have an Antwerp party mid Feb? 
> 
> 2017-01-18 11:15 GMT+01:00 Ben Laenen :
> 
>> At the meetup I was jokingly proposing to do an informal meetup/party in
>> Antwerp to celebrate ten years of being an OSM member next month :-p But I
>> don't care too much if it's in Brussels, as there are probably quite a few
>> other people in the community who have their ten year celebration coming up 
>> in
>> 2017 without realizing it since 2007 was the time when things started to
>> appear on the map in Belgium...
>> 
>> Ben
>> 
>> On Tuesday, 17 January 2017 21:35:28 CET Bessières, Marc wrote:
>>> En Français + bas.
>>> 
>>> Hello,
>>> 
>>> After the very nice meeting yesterday, I would like to organise another
>>> meeting in BXL next month.
>>> 
>>> So I'd like to do it a day which would be good for at least some
>>> persons.
>>> 
>>> And then invite everybody who would like to join but doesn't know it yet
>>> 
>>> :)
>>> 
>>> I proposed only beginning of the weeks in order to have enough room in
>>> the bar.
>>> 
>>> https://framadate.org/ysSVQHfkaanXINNV [1]
>>> 
>>> Bonjour,
>>> 
>>> Après la super réunion d'hier je voudrai organiser un nouveau meeting a
>>> BXL le mois prochain
>>> 
>>> Et pour ça je voudrais choisir une date qui convienne au moins à
>>> quelques personnes.
>>> 
>>> Et ensuite je posterai l'invitation pour toute personne intéressée mais
>>> qui ne le sait pas encore :)
>>> 
>>> Je ne propose que des jours en début de semaine, afin d'avoir assez de
>>> place dans le bar.
>>> 
>>> https://framadate.org/ysSVQHfkaanXINNV [1]
>> 
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be [2]
> 
> -- 
> 
> Joost Schouppe 
> OpenStreetMap [3] | Twitter [4] | LinkedIn [5] | Meetup [6] 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

  

Links:
--
[1] https://framadate.org/ysSVQHfkaanXINNV
[2] https://lists.openstreetmap.org/listinfo/talk-be
[3] http://www.openstreetmap.org/user/joost%20schouppe/
[4] https://twitter.com/joostjakob
[5] https://www.linkedin.com/pub/joost-schouppe/48/939/603
[6] http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Mikoláš Štrajt]

Zdar,



vzhledem k tomu, že jsem taky autor rendereru (https://github.com/severak/
lunarender), dodal bych rád svůj pohled na věc:




Do dat bych nezalomitelnou mezeru (dále jen NBSP) raději nedával. Dovedu si 
hodně živě představit, že s NBSP něco (renderer, geokóder, editor) co 
zpracovává OSM data nepočítá a výsledkem budou nějaké bizarní chyby, které 
navíc nebude jednoduché odhalit, protože NBSP se zobrazuje jako bílý znak.




Dokonce mě překvapilo, že se vůbec zalamují dlouhé názvy. :-)





Bílé znaky jsou v tomhle celkem svinstvo, pamatuju si jak u nás ve firmě 
přestaly fungovat jakési XML exporty, protože do dat klienti kopírovaly 
(netisknutelné) řídící znaky z Wordu. Vtip byl v tom, že některé bílé znaky 
nejsou validní v XML.




-- Mikoláš Štrajt / Severák / http://severak.svita.cz/





PS: můj renderer "vykresluje" celé názvy na jednom řádku



-- Původní zpráva --
Od: LukášKaras 
Komu: talk-cz@openstreetmap.org
Datum: 17. 1. 2017 8:47:10
Předmět: [Talk-cz] Nedělitelná mezera v OSM datech

"Ahoj, o víkendu autor OSM Scout knihovny přidal užitečnou funkcionalitu
- zalamování dlouhých popisků do více řádků. Dle očekávání se ale názvy 
zalamují v místech kde vykreslovací engine uzná za vhodné, nikoliv tam kde 
je to správně (předložky zůstávají na konci řádku), například:

Libčice nad
Vltavou

Týnec nad
Sázavou

Tam lze "nad" na konci řádku ještě tolerovat i když mě osobně se nelibí, 
ale u "u": 

Nová ves u 
Chýnova

Je to typograficky špatně. Stejným neduhem trpí i Mapnik.

Moje otázka zní, zda-li je žádoucí do OSM přidávat na taková místa 
nedělitelné 
mezery (v xml "", unicode znak U+00A0) a existuje na to nějaký postup 
jak to provést hromadně? Poradí si s tím běžné editory? Neztratí se ta 
mezera 
při první editaci? 

Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba opravit

renderer, ale bez ní nemá prostě šanci cokoliv hádat...

Lukáš
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-pt] Importação massiva na Anadia

[Aurelio Pires]

Olá a todos,

Para mim, este email do Gustavo é uma boa síntese do que está em causa.

 - Ocupação do solo: totalmente de acordo com a perspetiva apresentada.

 - Usos do solo: também estou de acordo. E tendo em consideração este 
entendimento, tenho colocado em Braga as áreas industriais representadas 
no PDM colocando a tag source = PDM Braga 2015 [1]. Também me parece que 
são poucas as classificações que possam ter interesse para o OSM; talvez 
as zonas residenciais novas ou a expansão das existentes, e talvez as 
novas zonas comerciais e zonas verdes previstas. Mas acho que tem de se 
analisar caso a caso.


 - Quanto às importações, tenho também o mesmo entendimento.

Da discussão que sobre estes tópicos se fizer aqui na lista, sugiro que 
se faça uma síntese das conclusões para colocar no OSM wiki PT [2].


 - Em relação ao primeiro SOTM-PT, acho que já começa a existir massa 
crítica suficiente e, por isso, acho que é oportuno fazê-lo; e desde já 
me disponibilizo para colaborar na organização.


 - Quanto à importação de Anadia, sou da opinião que devia ser retirada!

Abraço,

APires


[1] http://www.openstreetmap.org/way/259130983
[2] http://wiki.openstreetmap.org/wiki/WikiProject_Portugal



On 2017-01-18 0:12, Jorge Gustavo Rocha wrote:

Olá malta,

Acho que temos que promover uma discussão entre nós em torno do que tem
interesse em termos de usos e ocupação do solo.

Ocupação do solo (o que existe)

De repente, acho que coisas como a Corine Land Cover não têm interesse
nenhum: é informação obsoleta, feita para estatísticas europeias, com
uma escala e um erro que não interessa (ao OSM). Qualquer um de nós
conseguiria fazer melhor de forma sistemática, hoje, usando dados do
Sentinel-2, sem sair do computador.

Prefiro deveras que sejam os mapeadores a irem dizendo o que realmente
existe no terreno. Prefiro um mapa "menos" preenchido, mas "bem"
preenchido. O que está tem que estar bem.

Quando exigimos que as importações têm que ser discutidas é para isso
mesmo: para entrarem dados bons, e não dados para depois serem corrigidos.

Quando uma área, como Anadia, está toda preenchida, não sei o que está
bem e o que está mal. Infelizmente assumo que está tudo mal, mesmo que
um coitado de uma mapeador tenha já endireitado uma parte da importação.
Fica a dúvida sobre toda a área.

Nestes casos de importação, também acontece que (sem querer) quem faz a
importação está a exigir aos outros mapeadores que corrijam e conciliem
o que foi importado com o que estão a mapear. Eu gosto de mapear onde e
quando me apetece e não gosto tanto de estar condicionado pelas
importações dos outros.

Usos do solo (o que é permitido existir)

Coisas relacionadas com usos do solo (regulamentação), determinados por
PDM de Câmaras e afins, poderão ter algum interesse, mas muito limitado.
É preciso ver que usos interessam. Sei que o geospot_mike (Águeda) tem
as áreas industriais (que me parece interessante), mas pouco mais
informação é relevante.

Proposta para o primeiro SOTM-PT

Acho que a necessidade deste tipo de discussão nos "obriga" a organizar
o primeiro SOTM-PT "oficial". Já tivemos grandes parties e algumas
oficinas de dados, mas acho que podemos fazer um SOTM com uma certa
dimensão. Se gostarem da ideia, ofereço-me para começar a tratar da
organização.

Voltando a questão inicial dos usos e da ocupação do solo, gostava que
partilhassem a vossa opinião para depois tomar uma decisão. Estou
inclinado a pedir para retirarem a informação importada da Anadia.

Abraço,

J. Gustavo

Às 23:19 de 17-01-2017, Rui Oliveira escreveu:

Acho que cabe ao Jorge decidir como deseja proceder sendo que foi ele
que originalmente reportou a situação. Eu recebi a mensagem do
utilizador referido e assim que a obtive coloquei aqui na lista, logo
talvez o utilizador hhugboss tenha também respondido ao Jorge. Vamos
esperar para ver o que ele diz.

Cumprimentos

2017-01-17 18:25 GMT+00:00 Marcos Oliveira
>:

 Já se passou um mês, sempre é para deixar os dados no mapa?

 No dia 15 de dezembro de 2016 às 11:48, Pedro Pereira
 > escreveu:

 Bom dia,

 Uma vez que o Hugo refere "Sinceramente não percebo muito bem a
 necessidade de discutir tal procedimento", sugiro que se
 responda a explicar as implicações dessas alterações tais como:
 - problema direitos autor;
 - pode originar sobreposição com informação mais detalhada;
 - a lista poder ajudar no sentido de definir as tag's;
 - entre outros...

 No meu caso de importação tive o cuidado de fazer o carregamento
 por partes (apenas naquelas onde não existiam qq áreas - locais
 mais afastadas dos centros urbanos).

 Abraço,
 Pedro

 2016-12-15 11:19 GMT+00:00 Rui Oliveira >:

 Bom dia a todos.
 

[OSM-talk-be] Trappen opdelen

[Philippe Casteleyn]

Hier de link naar de metrouitgang.

http://www.openstreetmap.org/node/3141592603#map=19/50.85126/4.35319=D
[http://www.openstreetmap.org/assets/osm_logo_256-835a859acf0d378e1d14e88b15e7b4b95211ccd41a2c061b1629cfbbb8deb697.png]

OpenStreetMap | Node: ?3? 
(?3141592603?)
www.openstreetmap.org
OpenStreetMap is a map of the world, created by people like you and free to use 
under an open license.






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

[OSM-talk-be] Trappen opdelen.

[Philippe Casteleyn]

Ik ben in Brussel begonnen met de traptreden te tellen.

Heeft het zin de trappen op te delen tussen de bordessen, ook als de trap daar 
niet van richting verandert ?  Zijn er bezwaren ?  Ik heb al gedacht naar de 
brailleliga te bellen om het te vragen.

Ik heb al geprobeerd met de metrostation Brouckère, uitgang 3.  Die trap was al 
getekend.  Verder blijf ik liever af van metrostations.


Als het geen zin heeft, dan zet ik de 2 of 3 traptredes in een note tag.  En 
gelukkig bestaan er nog foto's.



























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

Re: [Talk-lt] Asociacija „Atvirasis žemėlapis“

[Tomas Straupis]

2017 m. sausio 18 d. 08:12, Darius Žitkevičius rašė:
> Puiki idėja.
> Kaip įstoti?

  Dar tvarkome formalumus. Stojimo idėja kol kas tokia: narystės
e-pašto adresu reikės siųsti laišką, pasirašytą elektroniniu parašu.
Elektroninis parašas reikalingas tam, kad galėtume kažkaip patikrinti,
ar žmogus, sakantis, kad jis yra Ainars Bemberis iš tiesų yra Ainars
Bemberis :-) Alternatyviai galima pasirodyti kuriame nors susitikime,
tada gal dokumentą kokį pažiūrėsime ar pan.

  Nebent yra minčių, kaip kitaip (be e-parašo) patikrinti žmogaus
tapatybę. Laukiame minčių/idėjų (šiuo ir kitais klausimais) iš visų
susidomėjusių!

  Daugiau informacijos bus paskelbta artimiausiu metu.

-- 
Tomas

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

Re: [Talk-GB] Named landuse polygons

[Ed Loach]

DaveF wrote:

> Please be aware this is the talk-GB forum.
> 
> Use of place=farm in Britain is almost certainly misguided. If anyone
> knows of an appropriate location please post here.
> 
> It's not use of the tag itself that's the problem, it's contributor's
> misinterpretation of it.

When was it redefined? 
https://wiki.openstreetmap.org/w/index.php?title=Key:place=373452
place=farm - A distinct identified farm at the node so tagged. In some 
countries the official type of a residential area smaller than a hamlet 
(Germany: Gehöft).

My reading of the proposal for place=isolated_dwelling
https://wiki.openstreetmap.org/wiki/Proposed_features/isolated_dwelling
is that place=isolated_dwelling is like place=farm but for places that aren't 
farms. This suggests the description on the place=farm wiki page is wrong.

Ed


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

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Jan Martinec]

Zrovna co se týče vyhledávání, tak není třeba se obávat: pokud má Nominatim
Unicode collation (spoiler: má), tak můžeš zadávat nejen normální mezery,
ale dokonce můžeš zadat "usti nad labem" bez diakritiky, a stejně to
matchne "Ústí nadLabem", páč whitespace jako whitespace. Máme už
století ovocného netopýra, nevyžadujeme uživatelský vstup přesně podle
stavu v db ;)

HPM

Dne 18. 1. 2017 10:33 napsal uživatel "majka" :

> No, já bych měla ještě jeden argument proti, a to opět mobilní aplikace
> užívající OSM data. Pokud dám do názvu pevnou mezeru, tak to v první fázi
> podle mě bude znamenat, že jí to bude očekávat i při vyhledávání. Na mobilu
> si dost dobře nedokážu představit. A ve svojí adrese bych jí měla hned jako
> druhý znak v názvu ulice, stačí že ještě poměrně nedávno ten název na
> cedulích a v dokumentech měl celkem 4 varianty, a to bez často užívané
> zkratky : )  U obce je to podobné, jsme "Horní Dolní u Většího města".
> Teoreticky je správná jen jedna varianta rozdělení, ale radši to přežiju
> zalomené špatně jak u ulice, tak u obce...
>
> Fakt jsem v tomhle staromilec a pamětník, ale unicode "formátovací" znaky
> považuju v tomhle za dost problematické.
>
> Majka
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[majka]

No, já bych měla ještě jeden argument proti, a to opět mobilní aplikace
užívající OSM data. Pokud dám do názvu pevnou mezeru, tak to v první fázi
podle mě bude znamenat, že jí to bude očekávat i při vyhledávání. Na mobilu
si dost dobře nedokážu představit. A ve svojí adrese bych jí měla hned jako
druhý znak v názvu ulice, stačí že ještě poměrně nedávno ten název na
cedulích a v dokumentech měl celkem 4 varianty, a to bez často užívané
zkratky : )  U obce je to podobné, jsme "Horní Dolní u Většího města".
Teoreticky je správná jen jedna varianta rozdělení, ale radši to přežiju
zalomené špatně jak u ulice, tak u obce...

Fakt jsem v tomhle staromilec a pamětník, ale unicode "formátovací" znaky
považuju v tomhle za dost problematické.

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

Re: [Talk-lv] Adrešu maiņa

[Aivars Miška]

Kaut kā apstrādāt publiski izlikto sēdes protokola pielikumu?
http://www.baldone.lv/images/userfiles/dome/lemumi/2016/par_zemes_adresu_mainu_baldones_pilseta.pdf

Aivars

-Original Message- 
From: pAnda71

Date: trešdiena, 2017. gada 18. janvāris 11:15
To: talk-lv
Subject: [Talk-lv] Adrešu maiņa

Sveiki.

Baldonē pagaišgad apstiprināja adrešu maiņu daudzām mājām -
oficiālajos dokumentos māju nosaukumu vietā tagad ir iela un numurs.
Varbūt kādam jau ir pieredze, kā dabūt šādu sarakstu no Domes (ideālā
gadījumā jau gatava vēstule ar pieprasījumu). Ja nav, kādas Jūsu
domas, kā rīkoties?

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



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

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Karel Volný]

čus,

> Forma by měla být oddělena od obsahu.

obecně souhlas, akorát se neshodneme v tom, co je obsah a co je forma

já nedělitelnou mezeru považuju za obsah, úplně stejně jako mezeru normální 
nebo téměř jakýkoliv jiný znak - přeci nejde o to, jak vypadá, ale jaký má v 
textu význam ... v některých případech (nejlépe fonty pro captcha :-)) 
nepoznám vizuálně malé "L" od velkého "i", popř. svislítka, například, ale 
zaměnit je nemohu, tak stejně tak nepoznám ty mezery, ale každá má jiný význam

problém je v tom, že člověk to takto nevnímá, protože narozdíl od hloupého 
počítače nezpracovává text po jednotlivých znacích, a pouze na konci řádku 
přemýšlí "smím zalomit?" namísto aby to řešil mezi každou dvojicí znaků po 
celý řádek, takže mu přijde nepřirozené si tam tu počítačovou reprezentaci 
odpovědi na "smím zalomit" připustit

kontrolní dotaz - používání malých a velkých písmen je obsah nebo forma?

> Zalamování řádek, dělení slov, skloňování a časování ať je záležitostí
> zpracování dat, ne jejich uložení.

skutečně toto vše? - takže bychom vlastně neměli mít "Libčice nad Vltavou" ale 
"Libčice nad Vltava"? :-)

jinak přijde mi smutné, že na konci druhé dekády 21. století tady padají 
argumenty jakože to nemáme dělat, protože to nemá podporu v editorech apod.

za sebe bych to viděl tak, že kdo to chce používat, ať si to používá, s tím, 
že je možné, že mu to někdo přeplácne, protože to neřeší(*), a pokud je to v 
nějakém editoru/jiném programu problém, jakože na tom padá nebo se k tomu 
nechová jako ke whitespace apod., tak ať se sakra ten software opraví

(*) já třeba nevím, jak na obyčejné Xové cz_qwerty nedělitelnou mezeru napsat, 
z nástroje na výběr znaků to extra vkládat nebudu ... jasně, v TeXu vlnka, v 
Libreoffice ctrl+mezera, ale jak to mám dostat jednoduše třeba do Merkaartoru?

nějaké hromadné zavádění nedělitelných mezer je IMHO zlo, pokud někdo dokáže 
vymyslet natolik dobrý algoritmus, aby byl použitelný pro hromadnou změnu(**), 
tak by měl být použitelný renderery, čímž by se celá diskuse stala 
bezpředmětnou

(**) pokud vím, zatím se to TeXpertům nepovedlo ani za ~30 let ...

tož asi tak ...

K.


signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] Cartographie des églises

[Nicolas Moyroud]

Bonjour Donat,

Bravo pour ce travail exhaustif sur les églises de Meurthe-et-Moselle !
Je complète moi-même régulièrement des noms d'églises manquants sur les 
départements du Languedoc-Roussillon en me basant sur le site 
clochers.org. Comme toi je me sers souvent des photos qui y sont 
proposées pour faire du repérage de formes afin d'être sur qu'il s'agit 
bien de la bonne église.
Vu le catalogue impressionnant qui est présent sur ce site, je me suis 
dis que ce serait utile d'avoir un lien entre les objets OSM et les 
identifiants des églises sur le site. Du coup j'ajoute également dans 
OSM un tag "ref:clochers.org" sur les églises en mettant le numéro qui 
se trouve dans l'URL de la page d'une église. Par exemple si c'est 
"accueil_48013.htm" je mets "48013". C'est souvent le code insee de la 
commune, mais pas toujours si il y a plusieurs édifices religieux sur la 
même commune (par exemple 48090a, 48090b).


Nicolas


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

Re: [Talk-cz] Nedělitelná mezera v OSM datech

[Lukáš Karas]

Ahoj. 

Děkuji všem za názory. Osobně si myslím že konkrétně pevné mezery do OSM 
patří. Stejně tak by měly být součástí běžných textů, jako třeba maily. 
To že to automatické korekce často neopravují a lidé běžně explicitně nepíší 
je jiná věc, ale je to pro mě hlavní argument proti. Lidé je zkrátka nejsou 
zvyklí používat a jejich podpora v editorech je nulová. 

Dne úterý 17. ledna 2017 19:43:40 CET jzvc napsal(a):
> Cus,
> 
> ja bych to neresil. Je to vec renederu. To jaky jazyk je primarni muze
> snadno zjistit - bud tak, ze se podiva s jakym lang tagem se shoduje,
> nebo tak, ze se podiva uvnitr jakych hranic lezi.
> 

Tím _snadno_ jsi mě poslal do kolen. Většina tagů nemá lang tag. 
Snadno to pozná člověk který dokáže na mapě najít státní hranice a otevřít si 
wikipedii aby dohledal jaký jazyk je v dané zemi (oblasti) primární. 
Teď si představ jak bys něco takového programoval... 

> 
> Jak bylo zmineno, to pak zacnem resit jestli se spravne deli slova, co
> je spojka a co predlozka ...


Dělení slov je trochu jiný problém a vůbec bych to k tomu nemíchal... 
Unicode znak na to sice existuje ale jeho použití je trochu nepraktické.
A už jste někdy viděli renderer který by se snažil dělit dlouhá slova?

Lukáš


> 
> Ono tohle porcovani podle mezer nefunguje spravne prakticky v zadnem
> existujicim jazyce.
> 
> Apropos, kdyz uz to zminujes … typograficky spravne by si nemel pouzivat
> "anglicky" ale „cesky“ uvozovky (a ja bych mel psat nabodenicka), stejne
> tak by se nemelo pouzivat spojovnik - ale pomlcka –(—) jedno pripadne
> dvouctvercikova, pripadne minus − (i kdyz to tak nevypada sou to 4 ruzny
> znaky)  ... ;D
> 
> 
> 
> Takovej vyber (vazne nevim jak to dopadne v tom mailu), je to popiska,
> znak (pokud je zobrazovanej), alt sekvence, hexa kod a html entita.
> 
> Uvozovky
> rovné uvozovky (na klávesnici)"   0034x0022   
> spodní uvozovky   „   0132x201E   
> horní uvozovky“   0147x201C   
> spodní jednoduchá uvozovka‚   0130x201A
> horní jednoduchá uvozovka ‘   0145x2018
> apostrof  ’   0146x2019
> francouzká otevírací uvozovka »   0187x00BB   
> francouzká uzavírací uvozovka «   0171x00AB   
> 
> Matematika
> X krát×   0215x00D7   
> děleno÷   0247x00F7   
> plus (na klávesnici)  +   0043x002B   
> mínus −   8722x2212   
> plus mínus±   0177x00B1   
> stupně°   0176x00B0   
> zeměpisné minuty  ′   2032x2032   
> promile   ‰   8240x2030   
> spojovník (na klávesnici) -   0045x002D
> rozdělovník = spojovník   x­x 0173
> pomlčka   –   0150
> dlouhá pomlčka—   0151
> výpustka  …   0133
> nedělitelná mezerax x 0160
> narození  *
> úmrtí †   0134
> euro  €   8364
> copyright ©   0169
> registrovaná značka   ®   0174
> m2㎡   13217
> 
> Dne 17.1.2017 v 8:45 Lukáš Karas napsal(a):
> > Ahoj, o víkendu autor OSM Scout knihovny přidal užitečnou funkcionalitu
> > 
> >   - zalamování dlouhých popisků do více řádků. Dle očekávání se ale názvy
> > 
> > zalamují v místech kde vykreslovací engine uzná za vhodné, nikoliv tam kde
> > je to správně (předložky zůstávají na konci řádku), například:
> > 
> > Libčice nad
> > 
> >Vltavou
> >   
> >   Týnec nad
> >   
> >Sázavou
> > 
> > Tam lze "nad" na konci řádku ještě tolerovat i když mě osobně se nelibí,
> > ale u "u":
> > 
> > Nová ves u
> > 
> >   Chýnova
> > 
> > Je to typograficky špatně. Stejným neduhem trpí i Mapnik.
> > 
> > Moje otázka zní, zda-li je žádoucí do OSM přidávat na taková místa
> > nedělitelné mezery (v xml "", unicode znak U+00A0) a existuje na to
> > nějaký postup jak to provést hromadně? Poradí si s tím běžné editory?
> > Neztratí se ta mezera při první editaci?
> > 
> > Pokud i s nedělitelnou mezerou to renderer zalomí špatně, je potřeba
> > opravit renderer, ale bez ní nemá prostě šanci cokoliv hádat...
> > 
> > Lukáš
> > 
> > 
> > 
> > ___
> > Talk-cz mailing list
> > Talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
> 
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz