Re: [OSRM-talk] OSRM demoserver update

[Daniel Patterson]

The swapover has been completed.  Please open tickets if you see any
server-move problems crop up.

daniel

On Fri, Oct 27, 2017 at 5:14 PM, Daniel Patterson  wrote:

> Hi everyone,
>
>   As most of you have probably noticed, the OSRM demoserver has been
> pretty unreliable over the last few months.
>
>   This weekend, I'm going to migrate it to live alongside our production
> infrastructure here at Mapbox.  This means it'll get redundancy and
> monitoring!
>
>   I'm hoping the transition is mostly seamless, but there will be a few
> changes you may notice:
>
> 1. We'll be switching from `osrm.routed`, to `osrm-routed.js` (
> https://github.com/Project-OSRM/osrm-backend/pull/4604).  I've tried my
> best to make it fully compatible, but, well, there are always bugs.
> 2. The demoserver will only run stable releases, it will no longer run
> from master.
> 3. The dataset is a slightly modified car.lua, *plus* Mapbox's
> freeflow traffic data over the top - this should give more accurate ETAs in
> areas where Mapbox has traffic coverage than plain car.lua.
> 4. Hints are disabled on the new setup - the hint= parameter is
> accepted but ignored.  This is because we're cycling the dataset every few
> hours behind the scenes, hints get invalidated quickly.
> 5. The demoserver will have a service-wide rate limit of 5000
> req/minute.  Looking at past logs, it stays below this about 98% of the
> time, but be prepared for HTTP 429 responses, and be aware that heavy usage
> may cause rate limiting for everyone else if you flood the server.
> 6. Some error messages will change - this is mostly the result of the
> switch from osrm-routed to osrm-routed.js and using a different URL parsing
> library.
>
>   I plan on doing the switchover starting now - there may be some DNS
> outage required while I do the reconfiguration.  Once the swapover is done,
> the hope is that we'll have a much more reliable service that costs us less
> money to operate.
>
>   If you notice any weirdness that seem the result of the switchover,
> please open tickets in the osrm-backend project.
>
> daniel
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[OSRM-talk] OSRM demoserver update

[Daniel Patterson]

Hi everyone,

  As most of you have probably noticed, the OSRM demoserver has been pretty
unreliable over the last few months.

  This weekend, I'm going to migrate it to live alongside our production
infrastructure here at Mapbox.  This means it'll get redundancy and
monitoring!

  I'm hoping the transition is mostly seamless, but there will be a few
changes you may notice:

1. We'll be switching from `osrm.routed`, to `osrm-routed.js` (
https://github.com/Project-OSRM/osrm-backend/pull/4604).  I've tried my
best to make it fully compatible, but, well, there are always bugs.
2. The demoserver will only run stable releases, it will no longer run
from master.
3. The dataset is a slightly modified car.lua, *plus* Mapbox's freeflow
traffic data over the top - this should give more accurate ETAs in areas
where Mapbox has traffic coverage than plain car.lua.
4. Hints are disabled on the new setup - the hint= parameter is
accepted but ignored.  This is because we're cycling the dataset every few
hours behind the scenes, hints get invalidated quickly.
5. The demoserver will have a service-wide rate limit of 5000
req/minute.  Looking at past logs, it stays below this about 98% of the
time, but be prepared for HTTP 429 responses, and be aware that heavy usage
may cause rate limiting for everyone else if you flood the server.
6. Some error messages will change - this is mostly the result of the
switch from osrm-routed to osrm-routed.js and using a different URL parsing
library.

  I plan on doing the switchover starting now - there may be some DNS
outage required while I do the reconfiguration.  Once the swapover is done,
the hope is that we'll have a much more reliable service that costs us less
money to operate.

  If you notice any weirdness that seem the result of the switchover,
please open tickets in the osrm-backend project.

daniel
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSM-talk] Topology rules

[Martin Koppenhoefer]

sent from a phone

> On 26. Oct 2017, at 23:48, Daniel Koć  wrote:
> 
> If you mean standard tile layer (osm-carto), landcover=* tag is far from 
> being accepted:
> 
> https://github.com/gravitystorm/openstreetmap-carto/issues/2548#issuecomment-330002296



most prominent argument seems to be waiting for more usage:
„
Other tags are used to indicate areas with trees 700x more frequently than 
landcover=trees
It is not be our aim to push new tags against existing ones in pursuit of more 
systematic key semantics
Current tagging practices for areas with trees are messy, with different people 
having different views on what the tags mean. This limits what you can infer 
from the data.
this switch would have a huge impact on many map styles
„


cheers,
Martin 




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

Re: [OSM-ja] [Talk-ko] Romanisation: a solution

[tomoya muramoto]

・日本語のアルファベット表記で`ja-Latn`を使用するのに賛成です。
・`ja-latn`等よりも`ja-Latn`を使いたいです。BCP47でも大文字が使われており、大文字を使うのが自然に見えます。規格でも、"case-insensitive"であるとは書かれていますが、大文字を使うのを"recommend"しています。
http://www.unicode.org/iso15924/faq.html#17
・一括変更にも賛成です。競合した場合はそのまま残しましょう。
・ついでに、`ja-Hira`,`ja-Kana`もやってしまいませんか？
・さらに言えば、韓国における漢字表記も決めてしまったほうがよいのでは？現在は`name:ko_hanja`が使われているようですが、`name:ko-Hani`でしょうか？自信ないですが。
https://ja.wikipedia.org/wiki/ISO_15924

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

Re: [OSM-talk-fr] Zone naturelle protégée, chemin à accès restreint

[marc marc]

Le 16. 10. 17 à 08:22, Nicolas Toublanc a écrit :

> Question 1)*
> Actuellement, on a les tags:
>   * highway: path
>   * foot: yes
pas de sens d'avoir foot=yes vu que c'est le cas par défaut.

> http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions#France
>  , 
> je suppose qu'il faut explicitement ajouter:
>   * bicycle: yes
pas celui là vu que c'est le cas par défaut

> Ou est-ce même plutôt designated qu'il faut utiliser, au lieu de yes 
> (au moins pour les piétons) ?
designed précise que le piéton doit prendre ce chemin (panneau ahdoc)
http://wiki.openstreetmap.org/wiki/FR:France_roads_tagging#Voies_pi.C3.A9tonnes.2C_pistes_cyclables

> Dans quel cas doit-on plutôt utiliser highway: footway ? 
> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway 
lorsqu'il y a un panneau "chemin piéton"

 > des chemins pour piétons et cyclistes,
 > explicitement interdits aux chevaux et véhicules motorisés,
 > mais accessibles au tracteur de service pour l'entretien.

j'aurais mis
highway=track (parce qu'il a la largeur pour accueillir les tracteurs)
horse=no
motor_vehicle=private

> *Question 2) *
> 
> Une partie des chemins sont interdits au public, et appelés "Zone de 
> quiétude", pour protéger la faune.
> 
> Comment indiquer cette restriction d'accès?

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

Re: [Talk-de] Garmin gmapsupp.img funktioniert nicht mehr mit qlandkartegt / qmapshack

[Andreas Tille]

Hi Moritz,

On Thu, Oct 26, 2017 at 11:26:05AM +0200, Moritz wrote:
> kannst du mir die img files zukommen lassen, dann kann ich mal bei mir mit
> qmapshack schauen (1.9.1) ob's tut.

http://fam-tille.de/tmp/osm/gmapsupp.img

(Bitte gib mir kurz Bescheid, wenn Du es heruntergeladen hast - der Server
hat nicht mehr so sehr viel Platz ...)

> Habe qmapshack zuletzt im Sommer mit Openmtb Karten genutzt.
> 
> Alternativ könntest du dir img-Files von extract.bbbike.org runterladen.
> 
> Ich habe es gerade mit dieser Karte[1] und qmapshack probiert (falls sie
> nicht mehr verfügbar ist, dann hier[2] neu bauen).
> 
> Dann würdest du erstmal sehen, obs an dir oder den Karten liegt.
> 
> > Was kann ich tun, um eine Tour zu planen und eine GPX-Ausgabe
> > zu bekommen (es müssen nun nicht notwendig diese Programme sein,
> > aber die Web-Routenplaner, die dann auf eine APP aufsetzen
> > nützen mir nichts).
> 
> Ich nutze inzwischen recht häufig brouter-web [3]. Da fällt dann ein GPX
> raus, was sich einfach auf den Garmin übertragen lässt.

Danke für die hilfreichen Tips, die ich mir bei Gelegenheit ansehen
werde.

Viele Grüße

   Andreas.

-- 
http://fam-tille.de

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

Re: [Talk-de] Tag:building=slurry_tank

[Martin Koppenhoefer]

Am 27. Oktober 2017 um 22:06 schrieb Helmut Kauer :

> Griaß eich,
>
> mir ist folgender Widerspruch im Wiki aufgefallen:
>
> Die "Odelgrube" Tag:building=slurry_tank ist als building angegeben,
> auch im englischen Orginal. Es wird dann auch auf man_made=
>
> storage_tank verwiesen. Dort ist aber die Benutzung von building als
> falsch genannt.
>
> Es gibt ja auch noch verschiedene Bauweisen, welche noch nicht erfasst /
> beschrieben sind. Es gibt eine offene Bauweise, eine geschlossene, also
> mit Deckel, wobei diese meistens eben in den Boden eingelassen und und
> befahren werden können (meist an der runden Betonplatte erkennbar.
>
> Sollte da das Wiki nicht angepasst / ergänzt werden?
>
>


sind das nicht 2 unterschiedliche Dinge, eine offene Jauche/Gülle-Grube und
ein entsprechender Tank?

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

[Talk-de] Tag:building=slurry_tank

[Helmut Kauer]

Griaß eich,

mir ist folgender Widerspruch im Wiki aufgefallen:

Die "Odelgrube" Tag:building=slurry_tank ist als building angegeben,
auch im englischen Orginal. Es wird dann auch auf man_made=

storage_tank verwiesen. Dort ist aber die Benutzung von building als
falsch genannt. 

Es gibt ja auch noch verschiedene Bauweisen, welche noch nicht erfasst /
beschrieben sind. Es gibt eine offene Bauweise, eine geschlossene, also
mit Deckel, wobei diese meistens eben in den Boden eingelassen und und
befahren werden können (meist an der runden Betonplatte erkennbar.

Sollte da das Wiki nicht angepasst / ergänzt werden?

-- 
Helmut Kauer
Bodelschwinghstraße 35
83301 Traunreut
Tel.: +49 08669 1309340
Fax: +49 08669 1309343
Mobil 0176 50117047
E-Mail: li...@helmut-kauer.de

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

Re: [OSM-talk] Woods vs Forests

[Warin]

On 27-Oct-17 08:21 PM, Daniel Koć wrote:



I have no idea what "landform" can be, so I don't have an opinion on 
that.


Some land forms;
peak
cliff
saddle
ridge
valley



However "natural" key for trees ( 
https://taginfo.openstreetmap.org/tags/natural=trees maybe?) sounds 
perfectly valid for me.



And not to me.


Does it still sound valid for a flower bead that is replanted with fresh 
fully grown flower plants each year?


Or would that be better tagged as landcover?


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

Re: [OSM-talk] Woods vs Forests

[Warin]

On 27-Oct-17 09:17 PM, James wrote:

landuse= man made and maintained
natrual= it made itself(which is 99.9% of the time the case)


Two different things.

'landuse' does not imply man made, but the use of the land.

'natural' implies made by nature, and this is hard for a mapper to be 
certain of.




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

Re: [OSM-talk] Woods vs Forests

[Warin]

On 27-Oct-17 08:25 PM, Dave F wrote:
You appear to be differentiating based on size & location which, 
seeing OSM's output is visual & geospatial seems unnecessary.


*All* groups of trees are 'natural' so there should only be one 
primary tag. All "purposes" should be within sub-tags.





Your definition of 'natural' must be different for mine. :)

A tree that is grown in a nursery from grafted stock, planted and 
nurtured in a green house and then finally planted outside ... to me is 
not 'natural'.
A 'natural' tree grown from a seed that comes off a tree by natural 
means, falls to the ground and than grows without human interference to 
full size.


--
? "All "purposes" should be within sub-tags. "
Umm  so you would remove landuse? landuse=residential would be a subtag 
.. under what?


I think landuse is a good classification and should remain.
Areas used for forestry should be able to be tagged under a landuse tag. 
If the present landuse=forest is confusing then change it .. to, say 
landuse=forestry.




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

Re: [Talk-it] Manutentori attrezzature antincendio

[Andreas Lattmann]

Grazie Simone.

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [OSM-talk] Woods vs Forests

[Warin]

On 27-Oct-17 09:49 PM, Tomas Straupis wrote:

2017-10-27 12:25 GMT+03:00 Dave F wrote:

You appear to be differentiating based on size & location which, seeing
OSM's output is visual & geospatial seems unnecessary.

   If we make no such distinction, then in order to be topographically
correct, we would have to "cut out" (create multipolygons) for each
small wood areas with 10 trees inside say residential area.


*All* groups of trees are 'natural' so there should only be one primary tag.
All "purposes" should be within sub-tags.

   Fine. Let's say in higher level there is only one "forest". Then my
topic moves one layer down and stays exactly the same otherwise.
   What I'm talking is about virtual hierarchy.
   OSM tagging comes AFTER that.



What you are talking about looks to be the rendering into layers and 
which layer comes higher than the other.


That is the choice of the render and what could be higher in one 
rendering could be the lower in another rendering.



Within the data base of OSM the distinctions need to be clear between 
these classifications so there is no cross over, no confusion.


Which classification is 'higher' than another has no effect on how it is 
stored in the OSM data base.


And tagging is about the storage of things in the OSM data base - trying 
to make it clear, organised and usable for both tagger and render.




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

Re: [OSM-talk-fr] harmonisation et nettoyage toilets:wheelchair en allemagne

[osm . sanspourriel]

En théorie, je vois bien les raisons de JB.

En pratique vu que ce sont notamment des Allemands qui parlent sur le 
ticket de demander à talk-de, je ne vois pas trop le souci.


Je n'ai pas de problème de langue (pour l'allemand s'entend) mais un 
gros problème de temps pour pouvoir me proposer de faire l'interface.


Jean-Yvon


Le 27/10/2017 à 21:29, JB - jb...@mailoo.org a écrit :

PS: j'ai aussi posté à la racine du problème :
https://github.com/sozialhelden/wheelmap/issues/588


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

Re: [OSM-talk] Woods vs Forests

[Warin]

On 27-Oct-17 09:20 PM, Martin Koppenhoefer wrote:


I can't ignore the landcover argument in this context, and still 
believe the natural= key should mean: "a geographic feature", not 
"something natural" (as opposed to artificial). I would tag a peak 
with natural=peak regardless of human intervention, it's a peak.  In 
this sense, natural=wood means a "wood", and as not all areas of trees 
are woods, I'd question this statement.


A peak, yes. But where the entire hill is made from the tailings of an 
open cut mine (very large - both the hill and the mine) I don't think it 
can be said to be 'natural'. It is man made.
And this particular peak is prominent in the surrounding landscape, it 
is used as a tourist view point for the district.


As with other entities, any further details which gives clarity
should be provided in sub-tags.



as always, all tags should make sense, subtags are for further 
details, not to adjust/relativise the meaning of the main tag.

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

Re: [Talk-it] [talk-it] Allarme allagamento fine corso Sesia

[Marcello]

Ho il sospetto che non sia un problema di coastline, innanzitutto il
problema è presente anche in zone interne, dove c'è un corso d'acqua
sembra che il rendering sovrapponga l'acqua a tutti i tipi di landuse
tranne le foreste, poi ho fatto un controllo e non ho trovato
interruzioni nella coastline, almeno nel tratto italiano.

Il 27/10/2017 14:47, Simone Saviolo ha scritto:
> Il giorno 27 ottobre 2017 14:39, Alessandro Palmas
>  > ha scritto:
>
> E' qualche settimana che girando per l'Italia trovo parecchie tile
> allagate, potrebbe essere stato un taglio della coastline.
>
>
> Sto seguendo il corso del Ticino: dalla sorgente del Ticino, a nord
> della Val d'Ossola, fino a Frutigen, c'è un problema simile... nel
> pieno della Svizzera. Credo proprio che non si tratti di un problema
> con un fiume a questo punto. 
>
> Esiste un coastline/lake/riverbank checker?
>
> Ciao,
>
> Simone 

Ciao
Marcello

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

Re: [OSM-talk-fr] harmonisation et nettoyage toilets:wheelchair en allemagne

[JB]

Franchement, je pense que ce n'est pas une bonne idée.
La communauté allemande est bien structurée.
Ils ont apparemment identifié le problème.
Ça peut sembler long pour un Français, mais ça ne me choque pas qu'ils 
prennent plusieurs mois pour aboutir à la modification.

Tu (nous) n'es pas en liaison régulière avec la liste talk-de.
Tu ne pourras pas interagir avec leurs réponses en allemand.
Tu vas passer pour le *** français donneur de leçons qui ferait mieux de 
rester de son côté de la frontière.
Voilà voilà pour ce soir, le coté mondial, je le laisse de côté pour 
l'instant.

JB.

Le 27/10/2017 à 21:15, marc marc a écrit :

Bonsoir,

comme déjà effectué en France et en Suisse, j'aimerai lancer une édition
mécanique pour harmoniser et nettoyer les typos et erreur relatif à
toilets:wheelchair ce qui nécessite de demander l'avis de la communauté
via la mailing allemande talk-de

Mon soucis est la langue.. Je ne parle malheureusement pas allemand.
Je peux bien sur poster en anglais mais je trouve cela peu agréable pour
les allemands qui ne le parlent pas nécessairement tous.
Je peux bien sur passer mon message dans un traducteur automatique
et faire de même avec les réponses.
Ce serrait cependant mieux si quelqu'un parlant allemand pouvait
accompagner ma démarche tant pour le premier message (les traducteur
automatiques ne sont pas toujours parfait) que dans le cas (encore
hypothétique) où il y aurait discussion sur l'opération.

Quelqu'un de motivé ? je n'ai pas l'impression que cela devrait
générer beaucoup de volume.

PS: j'ai aussi posté à la racine du problème :
https://github.com/sozialhelden/wheelmap/issues/588

PS2: l'étape d'après, c'est au niveau mondial, mais j'espère que ce
serra une formalité vu que les pays les plus concernés l'auront fait.

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: [OSM-talk-fr] Devenir mandataire d'OpenStreetMap France

[marc marc]

Le 06. 10. 17 à 14:52, Vincent de Château-Thierry a écrit :
> On parle peu de l'association OpenStreetMap France sur ce canal. Je prends 
> l'occasion aujourd'hui pour aborder le sujet des mandataires.

bonne initiative :)

> Les demandes sont de tous ordres : dépannage technique, devis, participation 
> à une réunion ou à un événement, annonce.

est-ce qu'il y a une liste des demandes passées ?
cela pourrait permettre de se faire une idée de ce qui est demandé
est-ce qu'il y a un endroit où le suivit est fait ?
cela permettrait de se faire une idée du type de demandes pour 
lesquelles il manque du monde
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] harmonisation et nettoyage toilets:wheelchair en allemagne

[marc marc]

Bonsoir,

comme déjà effectué en France et en Suisse, j'aimerai lancer une édition 
mécanique pour harmoniser et nettoyer les typos et erreur relatif à 
toilets:wheelchair ce qui nécessite de demander l'avis de la communauté 
via la mailing allemande talk-de

Mon soucis est la langue.. Je ne parle malheureusement pas allemand.
Je peux bien sur poster en anglais mais je trouve cela peu agréable pour
les allemands qui ne le parlent pas nécessairement tous.
Je peux bien sur passer mon message dans un traducteur automatique
et faire de même avec les réponses.
Ce serrait cependant mieux si quelqu'un parlant allemand pouvait 
accompagner ma démarche tant pour le premier message (les traducteur 
automatiques ne sont pas toujours parfait) que dans le cas (encore 
hypothétique) où il y aurait discussion sur l'opération.

Quelqu'un de motivé ? je n'ai pas l'impression que cela devrait
générer beaucoup de volume.

PS: j'ai aussi posté à la racine du problème :
https://github.com/sozialhelden/wheelmap/issues/588

PS2: l'étape d'après, c'est au niveau mondial, mais j'espère que ce 
serra une formalité vu que les pays les plus concernés l'auront fait.

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

Re: [Talk-it] Manutentori attrezzature antincendio

[liste DOT girarsi AT posteo DOT eu]

Il 27/10/2017 12:26, Andreas Lattmann ha scritto:

Ok, nessuno sa come aiutarmi... :'(

Andreas Lattmann



Purtroppo su taginfo trovo solo questi:

https://taginfo.openstreetmap.org/search?q=shop+safety#values

Direi che al momento, salvo pareri diversi, si vada di shop=safety, non 
saprei altrimenti.


Per la manutenzione non so come taggare sinceramente.

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

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

Re: [Talk-ca] Carleton University Mapathon

[Javier Carranza]

Hi there,

We are a group of Latino mappers working with OSM since 2010. We have
advocated for the collaboration between civil society and governments uisng
OSM specially with National Stats Offices, having undertaken many
initiatives like this
https://undataforum.org/WorldDataForum/harnessing-census-data-collection-with-citizen-participation-in-the-sdgs/
 .

Related to this agenda, we will be organizing close to  INEGI (Natnl Stats
from México) next November a Mapathon
*http://osmgeoweek.org/event/aguascalientes/
* to out reach to local
mappers in the region. Officers from other National Statistics Offices from
Latin America are also invited to the event. We will be focusing on the OSM
Canada Task Manager and  trying to map remote regions.

Maybe we can partner to co organize our mapathons together, sharing
experiences and presentations from Canada and Mexico on line.

What do you think about this?

All best

[image: geocensos]
*Javier Carranza** Tresoldi** CEO*

*, GeoCensos@geocensos*Skype: javiercarranza
https://www.youtube.com/watch?v=9cfdYdQHZVY
Colombia Mobile:(57) 314-3244540
Panama Mobile: (507) 688 - 04892
www.geocensos.com
*Lets map together a better world*
 [image: Twitter]
 [image: LinkedIn]


"La información aquí contenida es para uso exclusivo de la persona o
entidad de destino. Está estrictamente prohibida su utilización, copia,
descarga, distribución, modificación y/o reproducción total o parcial, sin
el permiso expreso del representante legal de Fundación Geocensos, pues su
contenido puede ser de carácter confidencial y/o contener material
privilegiado. Si usted recibió esta información por error, por favor
contacte en forma inmediata a quien la envió y borre este material de su
computador. La Fundación GeoCensos no es responsable por la información
contenida en esta comunicación, el directo responsable es quien la firma o
el autor de la misma."

On Wed, Oct 25, 2017 at 11:50 PM, Kent Jacobs  wrote:

> Hello all!
>
>
>
> I am a Masters of Science student in the Geography department at Carleton
> University studying Quality Assessment of OSM data for my thesis. I am also
> currently employed at Employment and Social Development Canada as a
> Geomatics Technician where I have been promoting the use of OSM data within
> the department.
>
>
>
> I discussed the idea of a possible mapathon at Carleton University with
> Statistics Canada, the Carleton Geography department and Mapbox. I am
> reaching out (similar to Tim’s post above) to find additional OSM mappers
> to assist us with the mapathon. I am fairly experienced with OSM myself but
> I have never led a mapathon event. I am aware of COMS2200 issues with
> contributions and do not want a repeat of this.  I believe focusing on
> the OSM Canada Task Manager and rural/remote regions will help avoid poor
> contributions.
>
>
>
> Any help is much appreciated!
>
>
>
> Regards,
>
> Kent
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-it] [talk-it] Allarme allagamento fine corso Sesia

[Daniele Forsi]

Il 27 ottobre 2017 14:47, Simone Saviolo ha scritto:

> Esiste un coastline/lake/riverbank checker?

per la coastline c'è questo, ma mi sembra strano che in questo momento
non faccia vedere almeno un errore da qualche parte nel mondo, siamo
diventati così precisi? :-)
http://tools.geofabrik.de/osmi/?view=coastline

-- 
Daniele Forsi

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

Re: [Talk-de] Deutsche Namens-Tags in Polen

[Richard]

On Thu, Oct 26, 2017 at 03:46:08PM +0200, Martin Koppenhoefer wrote:
> Am 26. Oktober 2017 um 14:56 schrieb Richard :
> 
> > abgesehen von der poltisch-moralischen Dimension ist es Unfug irgendwelche
> > Namen einzutragen die
> > * dem Großteil der Nutzer und Einwohner nicht geläufig sind
> > * sich auf keiner Ortstafel uä finden.
> >
> >
> 
> 
> nach dieser Argumentation dürfte man überhaupt keine anderen Namen als die
> lokalen eintragen, weil die Einwohner kennen normalerweise vor allem ihre
> eigene Sprache, der Großteil der Nutzer wird immer unterschiedliche
> Sprachen sprechen und Ortstafeln geben normalerweise auch nur die
> offiziellen Namen an.

war das nicht mal so, daß gemappt werden soll was "am Boden" sichtbar ist? 

Zumindest sollte klar sein, daß irgendwelche ausländischen Namen nicht ins 
name:XX gehören sofern nicht die Mehrheit von/aus XX den Ort unter diesem 
Namen kennt. Und wenn die Mehrheit von XX den Ort überhaupt nicht kennt
ganz sicher auch nicht.

Nix dagegen die als _alt:XX, _old:XX oder sonstwas zu haben.

> > Mit so einer Karte findet keiner den Weg!
>  
> Es geht ja nicht nur darum, den Weg vor Ort zu finden. Und es ist auch
> nicht gesagt, dass nur weil ein Name in der eigenen Sprache in OSM
> eingetragen ist, man als Anwender dann keine anderen Sprachen (wie z.B. die
> vor Ort geläufigen) mehr angezeigt bekommt.

hoffentlich funktioniert das dann auch. Was heißt vor Ort geläufig.. in 
vielen kleinen Bergdörfern sind Namen geläufig die 5 km weiter nicht
mal richtig ausgesprochen werden.

Richard

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

Re: [Talk-it] [talk-it] Allarme allagamento fine corso Sesia

[Simone Saviolo]

Il giorno 27 ottobre 2017 14:39, Alessandro Palmas <
alessandro.pal...@wikimedia.it> ha scritto:
>
> E' qualche settimana che girando per l'Italia trovo parecchie tile
> allagate, potrebbe essere stato un taglio della coastline.
>

Sto seguendo il corso del Ticino: dalla sorgente del Ticino, a nord della
Val d'Ossola, fino a Frutigen, c'è un problema simile... nel pieno della
Svizzera. Credo proprio che non si tratti di un problema con un fiume a
questo punto.

Esiste un coastline/lake/riverbank checker?

Ciao,

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

Re: [Talk-it] [talk-it] Allarme allagamento fine corso Sesia

[Alessandro Palmas]

  
  
Il 27/10/2017 14:33, Simone Saviolo ha
  scritto:


  ...


Chi ha qualche idea più efficace delle mie?
  


E' qualche settimana che girando per l'Italia trovo parecchie tile
allagate, potrebbe essere stato un taglio della coastline.

Per alcuni tipi di oggetti prima o poi bisognerà pensare ad un
metodo che ne impedisca la modifica immediata.

Alessandro Ale_Zena_IT
  


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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Cascafico Giovanni]

Nessuno si arroga il potere di "autorizzare", ma semplicemente ricordiamoci
che la procedura di import e relativa wiki servono a qualcosa.
Non si é discusso a suo tempo, ci tocca farlo oggi.

Il 27/ott/2017 12:43, "Fabrizio Tambussa"  ha scritto:

> Siate onesti.
> Dite "Li vogliamo cancellare perché. ..", non dite "è un import
> mascherato/non autorizzato allora sono da cancellare".
> Saluti
> Fabrizio
>
> ___
> 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

[Talk-it] [talk-it] Allarme allagamento fine corso Sesia

[Simone Saviolo]

Ciao a tutti,

già ieri ho notato un allagamento intorno all'ultimo tratto del Sesia [1].
Se a Vercelli le risaie mappate stanno facendo un ottimo lavoro arginando
l'avanzamento delle acque, nella Lomellina tra Mortara e Casale la
situazione è più tragica.

Ho guardato i multipoligoni del Sesia e del Po e non ho trovato errori. Non
riesco a capire da dove venga tutta quell'acqua... dal Ticino? Da un errore
nel rilevamento della coastline? Il problema sembra confinato al quadratone
che vedete dal link (più o meno centrato nel quadrato), e solo a quel
livello di zoom.

Chi ha qualche idea più efficace delle mie?

Ciao,

Simone

[1] http://www.openstreetmap.org/#map=13/45.1907/8.6061
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Riseria

[Simone Saviolo]

Il giorno 27 ottobre 2017 13:19, Volker Schmidt  ha
scritto:

> Grazie.
> Sono d'accordo anche con questa proposta.
> Quello che mi lascia perplesso, che la metà della populazione mondiale
> mangia riso e ci sono solo na mnciata di rice_mill in OSM.
>

Purtroppo non riesco a trovare documentazione a riguardo, ma bisogna
considerare che un conto è il riso europeo e un conto quello asiatico. Non
solo le specie, ma anche l'utilizzo, la lavorazione e la cultura cambiano
enormemente. Infatti mi piacerebbe scoprire quanto hanno in comune una rice
mill filippina e una riseria del Vercellese o della Lomellina... non mi
stupirei se ci fossero differenze simili a quelle tra il gelato e l'ice
cream.

Ciao,

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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Cascafico Giovanni]

Non ho ancora visto density maps su flightradar24. Su maritime traffic
invece si... Ci sarà un motivo

Il 27/ott/2017 12:28, "Francesco Pelullo"  ha scritto:

>
>
> Il giorno 27 ottobre 2017 12:17, Alessandro Sarretta <
> alessandro.sarre...@gmail.com> ha scritto:
>
>> Chiedo per informazione: che differenza c'è tra quanto discusso e le
>> tracce dei traghetti in mare? Anche queste non sono "strade" reali e
>> piuttosto indicative della rotta.
>>
>
> Stavo per fare la stessa domanda.
>
> Ciao
> /niubii/
>
>
> ___
> 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: [OSM-talk] Woods vs Forests

[Tomas Straupis]

>>Fine. Let's say in higher level there is only one "forest". Then my
>> topic moves one layer down and stays exactly the same otherwise.
>>What I'm talking is about virtual hierarchy.
>>OSM tagging comes AFTER that.
>
> As I map & tag what I see in reality; could you expand on what you mean by
> "virtual hierarchy"?

  When you create a map (not a GIS database), you start with hierarchy
of objects which you're going to display. After that you specify what
exactly each of those items in the hierarchy is in your datasets. So
in the beginning you define an abstract reason/purpose, only then you
specify technical details (f.e. tags).
  I call this a virtual hierarchy of information.

  I do understand that a number of different approaches currently
exist in OSM. You could look around, see some objects which seem
interesting/important to you and then tag them by your best knowledge
using natural language concepts. And that is a problem, because even
with English speakers those "natural language concepts" are subjective
for a number of different reasons. So when we combine a set of
objects, tagged by different people with different subjective
understanding it is very hard to make a logical system which is
essential for quality use. And it also introduces too much arguing
later as we can see with this ten year long forest topic which is
nowhere close to agreement... even not closer than it was ten years
ago.

-- 
Tomas

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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Luca Delucchi]

2017-10-27 13:42 GMT+02:00 Martin Koppenhoefer :
>
>
> 2017-10-27 13:19 GMT+02:00 Luca Delucchi :
>>
>> 2017-10-27 13:00 GMT+02:00 Martin Koppenhoefer :
>>
>>
>> non è del tutto vero le rotte aeree per volo strumentale (tutti i voli
>> di linea per intenderci) sono rotte come quelle dei traghetti e
>> vengono modificate solo in caso di perturbazioni molto forti.
>
>
>
> no, ci sono più spazi, su altezze diverse, e il piloto sceglie prima di ogni
> volo la rotta.

si vero che ci sono più spazie ad altezze diverse, ma non lo sceglie
il pilota prima di ogni volo, le rotte aeree sono definite a priori e
c'è anche una tassa da pagare (poichè alcune sono più redditizie di
altre in base ai venti).
Le compagnie per ogni volo scelgono quale usare e solitamente tengono
quella sempre. Poi in caso di perturbazione che non permettono di
essere attraversate (prevalentemente cumulunembi) fanno delle
deviazioni

>
> Ciao,
> Martin
>


-- 
ciao
Luca

www.lucadelu.org

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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Martin Koppenhoefer]

ametto: OpenAviationMap non esiste più.

Forse perché le mappe si trovano apertamente in rete?

Comunque, se imaginate di trovare questo in OSM insieme a tutto il resto:
http://gis.icao.int/gallery/graphics/FLOWCHART2015.JPG
penso che un po' di confusione creerebbe tra tutti i mappatori.

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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Martin Koppenhoefer]

2017-10-27 13:19 GMT+02:00 Luca Delucchi :

> 2017-10-27 13:00 GMT+02:00 Martin Koppenhoefer :
>
>
> non è del tutto vero le rotte aeree per volo strumentale (tutti i voli
> di linea per intenderci) sono rotte come quelle dei traghetti e
> vengono modificate solo in caso di perturbazioni molto forti.



no, ci sono più spazi, su altezze diverse, e il piloto sceglie prima di
ogni volo la rotta.
Alcuni esempi puoi trovare qui:
https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/ifr/

esempi per qgis, high altitude
http://aeronav.faa.gov/enroute/10-12-2017/enr_h12.zip
low altitude: http://aeronav.faa.gov/enroute/10-12-2017/enr_l36.zip

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

Re: [OSM-talk] Woods vs Forests

[Dave F]

On 27/10/2017 11:49, Tomas Straupis wrote:


   If we make no such distinction, then in order to be topographically
correct, we would have to "cut out" (create multipolygons) for each
small wood areas with 10 trees inside say residential area.


Well, depending if it's a communal area or privately owned (& whether I 
can be bothered), I have done that. People don't, generally, live in trees.


Referring back to your previous comment about not overlapping; you 
appear to assume that 'landuse' is being used as the key.


The confusion of having two primary 'keys' for the same object is my 
main point.




   Fine. Let's say in higher level there is only one "forest". Then my
topic moves one layer down and stays exactly the same otherwise.
   What I'm talking is about virtual hierarchy.
   OSM tagging comes AFTER that.


As I map & tag what I see in reality; could you expand on what you mean 
by "virtual hierarchy"?


DaveF



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


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

Re: [Talk-de] Deutsche Namens-Tags in Polen

[SteMo]

Hi Michael,

das mag ja sein, daß es schon von verschiedenen Standpunkten aus
andiskutiert wurde. Gibt es denn auch entsprechende Dokumentationen im
Wiki? Ich bin noch über keine entsprechenden Hinweise gestolpert.

Hier mal eine Region, in der die Verwendung der Deutschen historischen
Namen sehr intensiv ist:
"https://www.openstreetmap.de/karte.html?zoom=9=53.16283=17.80117=B000;


Wer in der Region mal aktuell unterwegs war...
"Preußisch Friedland" ?? Zoomt gerne mal rein: z.B. Bahnhofsnamen (z.B.
"Obornik Großpolen", "Posen Eisenmühle", "Ketsch", "Samter", "Kreuz",
"Döllensradung" - "Posen Hauptbahnhof" geht ja noch) in Deutsch!
*ratlosKopfschüttel*


Viele Grüße
Stefan




Michael Reichert schrieb am 25.10.17 um 19:52:
> Hallo Stefan,
> 
> Am 25.10.2017 um 13:53 schrieb SteMo:
>> Wie steht Ihr dazu?
> 
> Das Thema ist schon oft genug durchgekaut worden. Ich kann mich an
> zahlreiche Diskussionen im Forum erinnern, hier eine Auswahl:
> 
> https://forum.openstreetmap.org/viewtopic.php?id=25131
> https://forum.openstreetmap.org/viewtopic.php?id=25719
> https://forum.openstreetmap.org/viewtopic.php?id=56459
> https://forum.openstreetmap.org/viewtopic.php?id=32361
> 
> Weitere Diskussionen findest du mit einschlägigen Suchbegriffen über die
> Suchmaschine deiner Wahl – vermutlich auch auf dieser Mailingliste.
> 
> Viele Grüße
> 
> Michael
> 
> 
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
> 


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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Luca Delucchi]

2017-10-27 13:00 GMT+02:00 Martin Koppenhoefer :

>
> è vero che sono indicative anche le tracce dei traghetti (ma molto più
> "reali" delle rotte aerei, che sono soltanto spazi di cui l'uso dipende
> molto dal tempo e altre condizioni), si potrebbe anche proporre di togliere
> le rotte, ma un po' di differenze per il significato in OSM lo vedo:

non è del tutto vero le rotte aeree per volo strumentale (tutti i voli
di linea per intenderci) sono rotte come quelle dei traghetti e
vengono modificate solo in caso di perturbazioni molto forti.

>
> Ciao,
> Martin
>


-- 
ciao
Luca

www.lucadelu.org

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

Re: [Talk-it] Riseria

[Volker Schmidt]

Grazie.
Sono d'accordo anche con questa proposta.
Quello che mi lascia perplesso, che la metà della populazione mondiale
mangia riso e ci sono solo na mnciata di rice_mill in OSM.
Volker

2017-10-27 11:22 GMT+02:00 Simone Saviolo :

> Il giorno 27 ottobre 2017 11:11, Volker Schmidt  ha
> scritto:
>
>> Come taggare una riseria?
>> Ho incontrato e mappato questa riseria [1] e ho utilizzato un tagging
>> provvisorio di mia invenzione dopo non aver trovato niente via taginfo e
>> wiki.
>> Qualcun altro ha gia mappato una riseria (rice mill)?
>>
>> [1] https://www.openstreetmap.org/way/230014439
>>
>
> Secondo me (vercellese, nato e cresciuto nel riso :) ma non agricoltore,
> né agronomo) una riseria è a tutti gli effetti una fabbrica: prende una
> materia prima (risone) e la trasforma (raffina) in un prodotto rivendibile
> (riso, ma anche la pula e la lolla che vanno ad altri trasformatori per
> farne concime o combustibile - o borse e magliette, visto come funziona
> oggi).
>
> Per prima cosa, quindi, userei landuse=industrial su tutta l'area, con il
> nome della riseria. I singoli edifici potrebbero eventualmente essere
> building=industrial. Quanto ad un tag specifico per il fatto che è una
> riseria, userei industrial=rice_mill sulla stessa way di
> landuse=industrial.
>
> Insomma, ricapitolando:
>
> landuse=industrial
> industrial=rice_mill
> name=Riseria Pippo
>
> industrial=rice_mill è già usato, anche se solo in due sole occasioni [2]
>
> Ciao,
>
> Simone
>
> [2] https://taginfo.openstreetmap.org/keys/industrial#values
>
> ___
> 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] Mappatura di oggetti "virtuali"

[Martin Koppenhoefer]

2017-10-27 12:17 GMT+02:00 Alessandro Sarretta <
alessandro.sarre...@gmail.com>:

> Chiedo per informazione: che differenza c'è tra quanto discusso e le
> tracce dei traghetti in mare? Anche queste non sono "strade" reali e
> piuttosto indicative della rotta.
>

è vero che sono indicative anche le tracce dei traghetti (ma molto più
"reali" delle rotte aerei, che sono soltanto spazi di cui l'uso dipende
molto dal tempo e altre condizioni), si potrebbe anche proporre di togliere
le rotte, ma un po' di differenze per il significato in OSM lo vedo:
1. "acceptance factor"/diffussione: a quanto pare, le rotte dei traghetti
sono molto più diffuse e usati da tanti mappatori diversi, i waypoint non
lo sono. https://taginfo.openstreetmap.org/tags/route=ferry#map
2. i waypoints sono esplicitamente esclusi perché non sono "tangibili", e
si rimanda ad un'altro progetto che raccoglie questi dati:
https://wiki.openstreetmap.org/wiki/Aeroways#Don.27t_map_airspace
"The regular on-the-ground rule
 of OSM
applies. If it’s something tangible that you can point at (like a runway,
helipad, or gate) then you can add it. If you can't do that (as with
airspace, routes, and aeronautical waypoints) then you should leave it out;
check out OpenAviationMap instead."
3. il tag route=ferry è documentato nella sua applicazione e nel suo
significato, per il tag aeroway=waypoint non ho trovato documentazione.

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

Re: [OSM-talk] Woods vs Forests

[Tomas Straupis]

2017-10-27 12:25 GMT+03:00 Dave F wrote:
> You appear to be differentiating based on size & location which, seeing
> OSM's output is visual & geospatial seems unnecessary.

  If we make no such distinction, then in order to be topographically
correct, we would have to "cut out" (create multipolygons) for each
small wood areas with 10 trees inside say residential area.

> *All* groups of trees are 'natural' so there should only be one primary tag.
> All "purposes" should be within sub-tags.

  Fine. Let's say in higher level there is only one "forest". Then my
topic moves one layer down and stays exactly the same otherwise.
  What I'm talking is about virtual hierarchy.
  OSM tagging comes AFTER that.

-- 
Tomas

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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Fabrizio Tambussa]

Siate onesti.
Dite "Li vogliamo cancellare perché. ..", non dite "è un import
mascherato/non autorizzato allora sono da cancellare".
Saluti
Fabrizio
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] Deutsche Namens-Tags in Polen

[SteMo]

Richard schrieb am 26.10.17 um 14:56:
> On Wed, Oct 25, 2017 at 03:19:04PM +0200, Martin Koppenhoefer wrote:
>>
>>
>> sent from a phone
>>
>>> On 25. Oct 2017, at 13:53, SteMo  wrote:
>>>
>>> 2. In Polen findet man, mit wenigen Ausnahmen auf historischen
>>> Baudenkmälern oder in Geschichtsbüchern _keine_ Verwendung dieser
>>> Bezeichnungen aus dem Dritten Reich.
>>
>>
>> Namen, die nur im Dritten Reich verwendet wurden, sollte man natürlich nicht 
>> in name:de eintragen, aber es gibt auch weit über diesen Zeitrahmen hinaus 
>> viele deutsche Namen, die unter, zumindest nach heutigem Maßstab, 
>> fragwürdigen bzw. “unmoralischen” Umständen in die Welt kamen, s.z.B. 
>> https://de.m.wikipedia.org/wiki/Germanisierung in Mittelalter und Neuzeit 
>> (vor 3.Reich). Englische, französische und spanische Namen sind z.B. im 
>> Kontext der Kolonialisierung auch betroffen (das relativiert nicht den 
>> Nationalsozialismus, sondern den deutschen Imperialismus des 19. Jh). Ob die 
>> Polen vor Ort deutsche Namen verwenden oder nicht sollte uns nicht daran 
>> hindern sie in name:de zu tun (wie gesagt, sofern es keine Namen aus der 
>> Kriegszeit sind), evtl. auch old_name:de. 
> 
> abgesehen von der poltisch-moralischen Dimension ist es Unfug irgendwelche 
> Namen einzutragen die
> * dem Großteil der Nutzer und Einwohner nicht geläufig sind
> * sich auf keiner Ortstafel uä finden.
> 
> Mit so einer Karte findet keiner den Weg! Wie blöd stehe ich in Verona 
> da wenn ich einen Italiener nach dem Bus nach Reif am Gart Frage?
> 
> Vielleicht mal als name:1939-1944 aber von prominenten Ausnahmen abgesehen
> gehört das wohl eher in die OHM?
> 
> Richard
> 

Ja, so finde ich es auch nachvollziehbarer.

Viele Grüße
Stefan


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

Re: [OSM-talk] Woods vs Forests

[Oleksiy Muzalyev]

On 27.10.17 12:20, Martin Koppenhoefer wrote:

[...]

isn't there a difference between using the wood that grows naturally 
(without being planted) and growing wood for using it?


[...]


Now woods are being planted also for the renaturation. Here is, as an 
example, an information board of the project of the renaturation on the 
river l'Hermance between the bridges Pont Neuf and Pont des Golettes 
https://commons.wikimedia.org/wiki/Category:Pont_Neuf_(Hermance)?uselang=fr#/media/File:Pont_Neuf_GE_10.jpg 
.


The river was canalized several decades ago, and now it is being 
returned to its original state, including woods along the river. It is 
practically impossible to tell if it is a natural or man-made forest, 
unless one knows it is a result of the renaturation.


Best regards,

O.

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

Re: [OSM-talk] Woods vs Forests

[Tomas Straupis]

> In; F1 there are the words "general landuse polygons"
>
> F2 there are the words "residential, commercial, industrial zones" that
> clearly imply land use.
>
> So your discussion is clearly about land use? Fine - that is ok.

  No. It is about virtual layers, calculated from OSM data for
cartographic, statistical or maybe some other use cases.

> I have an area that is used for recreation - picnics, walks, etc. It is a
> designated "National Park".
> So human land use is 'recreation'. There are native animals in there .. but
> the plan of management is primarily for 'recreation' and has been for many
> decades.

  My understanding is that all parks (national/regional and local
ones) are on a "higher" level "different GIS layer". That is on the
ground you still have a forest, water, meadow, rock, whatever. And
then on TOP of that you have an area of a "park". If you're interested
in parks - you render them on top of forest, meadow etc. objects. But
if you're not interested in parks you skip park objects and should
still get a good result with forests, meadows etc.
  Also if you're calculating how much forests there is in a region,
you want forests. It is not important if that forest is IN the park,
or not. You can simply ignore park objects.

  Or in other words, park is something I must KNOW. It is not
something I can see from say the airplane.

-- 
Tomas

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

[OSM-talk-fr] Rapprochement Bano

[gergero]

> Date: Thu, 26 Oct 2017 19:13:13 +0200
> From: gergero 

> J'ai une question par rapport aux données suivantes :
>
>   > (Message de Christian Quest Mer 25 Oct 13:55:58 UTC 2017 :)
>
>   > "Pour les points en violet, ce sont des adresses issues des 
fichiers du
>   > cadastre désormais en opendata. C'est un peu expérimental, mais 
ça peut

>   > être utile."
>
> Comment retrouver les données/fichiers à l'origine de ces adresses
> (points en violet) ?

Je trouve bien les coordonnées des points d'adresse en gris dans les 
fichiers BAN et BANO , mais les mêmes chiffres (adresses ? ) en violet 
me semblent plus à jour.



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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Andreas Lattmann]

>Chiedo per informazione: che differenza c'è tra quanto discusso e le 
>tracce dei traghetti in mare?

Suppongo che le tracce dei traghetti in mare sono più facilmente tracciabili 
(Sull'aereo ti fanno spegnere il cellulare).

Bella domanda comunque. Aspetto che qualcuno di più esperto dia una risposta.

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [OSM-talk-fr] Directions signalisations verticales

[Philippe Verdy]

Vous faites comment avec la signalisation au dessus de la route (accrochée
à un câble comme on en voit souvent aux USA, ou sur le tablier d'un pont,
ou sur une potence horizontale liée au seul des deux côtés de la route) ?
Noter aussi qu'un feu peut parfois être de l'autre côté du carrefour, avec
un seul poteau ayant des feux dans les deux directions.

D'une façon générale le feu n'est pas la seule signalisation, il y a aussi
le marquage au sol (un feu éteint pour une raison quelconque ne dispense
pas de respecter au moins les priorités à droite ou le stop s'il est marqué
d'une ligne continue, certains feux ayant en plus les panneaux
correspondants)

Ce que vous matérialisez sur le côté de la route ce n'est que le mobilier
qui supporte la signalisation, pas la signalisation elle-même. Dans ce cas
là pourquoi ne pas juste matérialiser le poteau (car il n'y en a pas
toujours pour tous les feux) ?

Le 27 octobre 2017 à 12:18, François Lacombe  a
écrit :

> Je pensais plus aux limitations de vitesse
>
> Pour les feux, comme les panneaux stop c'est un peu compliqué oui.
> Il faudrait mapper l'objet feu avec un nœud dédié, et la ligne
> matérialisant l’arrêt au sol sur la voie. On évite la redondance et on
> garde bien toutes les infos.
> Ça permettrait de tracer les sas velo devant les feux par exemple, auquel
> cas le feu n'est pas à la hauteur d'arret des voitures etc...
>
> Il y a aussi les panneaux périphériques, comme à l'approche d'un panneau
> stop pour prévenir les automobilistes, qui n'ont parfois aucun effet
> concret.
>
>
>
> Le 27 octobre 2017 à 12:09, marc marc  a écrit
> :
>
>> Bonjour,
>>
>> @Axelos:
>> Dans le cas de feux, la page dit que le tag direction permet de savoir
>> dans quel direction le feu s'applique, cela n'a donc pas de lien avec le
>> fait d'avoir le noeud tagé à sa position ou tagé sur le chemin qui
>> s'applique.
>> c'est plutot pour faire la distinction entre (apparement aux us) le cas
>> oü ils tag un carrefour avec un feu sur le croisement et le cas (partout
>> en europe ?) ou le feu est posé avant le carrefour et s'applique dans
>> une direction (qu'ils peux nécessaire de renseigner lorsque le feu se
>> trouve par exemple entre un rond-point et un passe piéton :
>> s'applique-t-i aux voitures qui rentrent dans le rond-point ou veux qui
>> en sortent pour laisser passer les piétons)
>> par contre le préfix traffic_signals est un peu inutile (vu que sur un
>> feu, il ne peu s'applique qu'aux feux)
>> mais puisque c'est ainsi que la propal est approuvé,je le fais ainsi
>>
>> @Francois j'ai pas compris comment tu met l'effet du feu sur le highway.
>> tu remet un 2ieme noeud avec les mêmes infos ?
>>
>> Le 27. 10. 17 à 11:55, François Lacombe a écrit :
>> > Bonjour Axelos,
>> >
>> > Je serais plutôt d'avis d'utiliser traffic_signals:direction sur tous
>> > les panneaux routiers pour indiquer la direction du trafic impactée.
>> > Si le panneau stop est cartographié à sa position réelle, direction=*
>> > s'applique.
>> >
>> > D'un point de vue perso, je cartographie les panneaux physiques à leur
>> > position réelle que dans c'est possible, et leurs effets sur la highway
>> > (ou sur ses noeuds)
>> >
>> >
>> > A+
>> >
>> > François
>> >
>> > Le 27 octobre 2017 à 11:03, Axelos a écrit :
>> >
>> > Coucou,
>> >
>> > J'ai dessellé une contradiction en ce qui concerne l'indication de
>> la
>> > direction concernant les signalisations verticales (feux, stop
>> > cédez-le-passage)
>> >
>> > En effet, si on prend l'exemple du feu de signalisation, on nous
>> demande
>> > d'utiliser le préfixe traffic_signals devant le tag direction pour y
>> > indiquer forward ou backward.
>> >
>> > Est alors expliqué que direction=* est utilisé pour indiquer les
>> points
>> > cardinaux si la signalisation n'est pas placée sur un chemin.
>> >
>> > https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
>> > 
>> >
>> > En toute logique, pour un stop, on devrait utiliser
>> stop:direction=*,
>> > hors c'est direction=* qui est indiqué.
>> > Pas de points cardinaux pour les stops ?
>> >
>> > https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Francesco Pelullo]

Il giorno 27 ottobre 2017 12:17, Alessandro Sarretta <
alessandro.sarre...@gmail.com> ha scritto:

> Chiedo per informazione: che differenza c'è tra quanto discusso e le
> tracce dei traghetti in mare? Anche queste non sono "strade" reali e
> piuttosto indicative della rotta.
>

Stavo per fare la stessa domanda.

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

Re: [Talk-it] Manutentori attrezzature antincendio

[Andreas Lattmann]

Ok, nessuno sa come aiutarmi... :'(

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [OSM-talk] Woods vs Forests

[Martin Koppenhoefer]

2017-10-27 0:49 GMT+02:00 Dave F :

> I think you'd be hard pressed to find any area of trees which hasn't been
> managed in one way or another by humans; especially in the Western world.
> Even in the depths of the Amazonian rainforest or Borneo the locals use
> wood for tools/fire/building etc.
>


isn't there a difference between using the wood that grows naturally
(without being planted) and growing wood for using it?




>
> Ignoring the landcover argument for a moment, all areas of trees should be
> primarily tagged as natural=wood.




I can't ignore the landcover argument in this context, and still believe
the natural= key should mean: "a geographic feature", not "something
natural" (as opposed to artificial). I would tag a peak with natural=peak
regardless of human intervention, it's a peak.  In this sense, natural=wood
means a "wood", and as not all areas of trees are woods, I'd question this
statement.



> As with other entities, any further details which gives clarity should be
> provided in sub-tags.
>


as always, all tags should make sense, subtags are for further details, not
to adjust/relativise the meaning of the main tag.

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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Alessandro Sarretta]

Chiedo per informazione: che differenza c'è tra quanto discusso e le 
tracce dei traghetti in mare? Anche queste non sono "strade" reali e 
piuttosto indicative della rotta.


Ale


On 27/10/2017 12:08, Martin Koppenhoefer wrote:



2017-10-27 10:19 GMT+02:00 Cascafico Giovanni >:


Ci sono 622 aeroway=waypoint nello spazio aerreo italiano, 1 in
California e 2 in Australia. Al resto del mondo pare non interessino.
Visto in nostro numero non esiguo, a suo tempo era stato discusso un
import?



Innanzitutto ben ritrovato David!

Concordo con Giovanni, ci sono vari aspetti. Si tratta chiaramente di 
un import, e non era stato ne discusso (se non sbaglio), ne fatto 
secondo le regole (che già c'erano all'epoca, anche se nel dettaglio 
ancora meno mature). Non è una particolarità di questo import, in quei 
tempi tanti importavano senza rispettare le regole, sopratutto quando 
la quantità di dati era tale da non creare attenzione.


Si tratta di pochi dati, che però, come dimostra l'utente Lola Fox, 
hanno già creato confusione e tendono a farlo, perché si riferiscono a 
qualcosa non osservabile e senza riferimento a terra. I dati del 
airspace e delle aerovie non sono osservabili o verificabili sennò con 
dati ufficiali, e perciò il contributo che un mappatore OSM può dare a 
questi dati è zero (non c'è potenziale di miglioramento attraverso la 
"crowd", la versione ufficiale non è "toccabile", i dati non hanno 
grandissima utiltà per farne una eccezione (come nel caso dei confini 
politici), OSM sarebbe soltanto un mezzo per distribuirli).


In generale, lo stato sui dati del airspace è di mappare le 
infrastrutture (radio fari ecc.) ma non i limiti legali / astratti 
come airspace, aerovie, ecc. perché si tratta di dati per specialisti, 
non migliorabili, non osservabili, estesi e quindi "disturbano" e 
"confondano" (meno pertinente per i punti di cui parliamo qui, ma la 
logica suggerirebbe di aggiungere anche le aree come passo successivo, 
no?).


Io sarei per togliere, visto che sono, come lo dice anche David, 
puramente "virtuali".


Visto che sono pochi punti, potrei anche tolerarli, ma formalmente non 
sono da tenere.


Ciao,
Martin



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


--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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

Re: [OSM-talk-fr] Directions signalisations verticales

[François Lacombe]

Je pensais plus aux limitations de vitesse

Pour les feux, comme les panneaux stop c'est un peu compliqué oui.
Il faudrait mapper l'objet feu avec un nœud dédié, et la ligne
matérialisant l’arrêt au sol sur la voie. On évite la redondance et on
garde bien toutes les infos.
Ça permettrait de tracer les sas velo devant les feux par exemple, auquel
cas le feu n'est pas à la hauteur d'arret des voitures etc...

Il y a aussi les panneaux périphériques, comme à l'approche d'un panneau
stop pour prévenir les automobilistes, qui n'ont parfois aucun effet
concret.


Le 27 octobre 2017 à 12:09, marc marc  a écrit :

> Bonjour,
>
> @Axelos:
> Dans le cas de feux, la page dit que le tag direction permet de savoir
> dans quel direction le feu s'applique, cela n'a donc pas de lien avec le
> fait d'avoir le noeud tagé à sa position ou tagé sur le chemin qui
> s'applique.
> c'est plutot pour faire la distinction entre (apparement aux us) le cas
> oü ils tag un carrefour avec un feu sur le croisement et le cas (partout
> en europe ?) ou le feu est posé avant le carrefour et s'applique dans
> une direction (qu'ils peux nécessaire de renseigner lorsque le feu se
> trouve par exemple entre un rond-point et un passe piéton :
> s'applique-t-i aux voitures qui rentrent dans le rond-point ou veux qui
> en sortent pour laisser passer les piétons)
> par contre le préfix traffic_signals est un peu inutile (vu que sur un
> feu, il ne peu s'applique qu'aux feux)
> mais puisque c'est ainsi que la propal est approuvé,je le fais ainsi
>
> @Francois j'ai pas compris comment tu met l'effet du feu sur le highway.
> tu remet un 2ieme noeud avec les mêmes infos ?
>
> Le 27. 10. 17 à 11:55, François Lacombe a écrit :
> > Bonjour Axelos,
> >
> > Je serais plutôt d'avis d'utiliser traffic_signals:direction sur tous
> > les panneaux routiers pour indiquer la direction du trafic impactée.
> > Si le panneau stop est cartographié à sa position réelle, direction=*
> > s'applique.
> >
> > D'un point de vue perso, je cartographie les panneaux physiques à leur
> > position réelle que dans c'est possible, et leurs effets sur la highway
> > (ou sur ses noeuds)
> >
> >
> > A+
> >
> > François
> >
> > Le 27 octobre 2017 à 11:03, Axelos a écrit :
> >
> > Coucou,
> >
> > J'ai dessellé une contradiction en ce qui concerne l'indication de la
> > direction concernant les signalisations verticales (feux, stop
> > cédez-le-passage)
> >
> > En effet, si on prend l'exemple du feu de signalisation, on nous
> demande
> > d'utiliser le préfixe traffic_signals devant le tag direction pour y
> > indiquer forward ou backward.
> >
> > Est alors expliqué que direction=* est utilisé pour indiquer les
> points
> > cardinaux si la signalisation n'est pas placée sur un chemin.
> >
> > https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
> > 
> >
> > En toute logique, pour un stop, on devrait utiliser stop:direction=*,
> > hors c'est direction=* qui est indiqué.
> > Pas de points cardinaux pour les stops ?
> >
> > https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Woods vs Forests

[James]

landuse= man made and maintained
natrual= it made itself(which is 99.9% of the time the case)

On Oct 27, 2017 5:27 AM, "Dave F"  wrote:

> You appear to be differentiating based on size & location which, seeing
> OSM's output is visual & geospatial seems unnecessary.
>
> *All* groups of trees are 'natural' so there should only be one primary
> tag. All "purposes" should be within sub-tags.
>
> DaveF
>
> On 27/10/2017 08:52, Tomas Straupis wrote:
>
>> Some info on how/why forest/wood tagging is used in Lithuania. I will
>> not give specific tags (forest vs wood, landuse vs natural etc),
>> because in my opinion that is a secondary issue. Let's say we have
>> tags F1 and F2.
>>
>> F1 is for general forests. Those are the ones depicted on small scale
>> maps (full country/region).
>>
>> F2 is for small wooded areas INSIDE other polygons, usually inside
>> residential, commercial, industrial zones.
>>
>> This approach ignores utility as such (managed, non managed, natural,
>> left for full nature cycles as mention in Oleksiy's post). This
>> information could be added as a sub-tag if needed for some thematic
>> maps or specific statistical calculations.
>>
>> What I'm saying is that maybe we should:
>> 1. first decide the PURPOSES of having "tree cluster" polygons tagged
>> separately.
>> 2. Then PRIORITISE the purposes (based on ACTUAL usage ignoring all
>> "it could theoretically be used to/for...")
>> 3. and then decide which info goes to primary tag, which goes to
>> secondary tag(s).
>> 4. And only THEN decide on actual tags (keys, values).
>> Doing it the other way round will take us back to this forest
>> discussion as it has been here for the last ten years like discussing
>> what the words "forest", "wood", "natural", "landuse", "landcover"
>> etc. actually mean.
>>
>>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Directions signalisations verticales

[marc marc]

Bonjour,

@Axelos:
Dans le cas de feux, la page dit que le tag direction permet de savoir 
dans quel direction le feu s'applique, cela n'a donc pas de lien avec le 
fait d'avoir le noeud tagé à sa position ou tagé sur le chemin qui 
s'applique.
c'est plutot pour faire la distinction entre (apparement aux us) le cas 
oü ils tag un carrefour avec un feu sur le croisement et le cas (partout 
en europe ?) ou le feu est posé avant le carrefour et s'applique dans 
une direction (qu'ils peux nécessaire de renseigner lorsque le feu se 
trouve par exemple entre un rond-point et un passe piéton : 
s'applique-t-i aux voitures qui rentrent dans le rond-point ou veux qui 
en sortent pour laisser passer les piétons)
par contre le préfix traffic_signals est un peu inutile (vu que sur un 
feu, il ne peu s'applique qu'aux feux)
mais puisque c'est ainsi que la propal est approuvé,je le fais ainsi

@Francois j'ai pas compris comment tu met l'effet du feu sur le highway. 
tu remet un 2ieme noeud avec les mêmes infos ?

Le 27. 10. 17 à 11:55, François Lacombe a écrit :
> Bonjour Axelos,
> 
> Je serais plutôt d'avis d'utiliser traffic_signals:direction sur tous 
> les panneaux routiers pour indiquer la direction du trafic impactée.
> Si le panneau stop est cartographié à sa position réelle, direction=* 
> s'applique.
> 
> D'un point de vue perso, je cartographie les panneaux physiques à leur 
> position réelle que dans c'est possible, et leurs effets sur la highway 
> (ou sur ses noeuds)
> 
> 
> A+
> 
> François
> 
> Le 27 octobre 2017 à 11:03, Axelos a écrit :
> 
> Coucou,
> 
> J'ai dessellé une contradiction en ce qui concerne l'indication de la
> direction concernant les signalisations verticales (feux, stop
> cédez-le-passage)
> 
> En effet, si on prend l'exemple du feu de signalisation, on nous demande
> d'utiliser le préfixe traffic_signals devant le tag direction pour y
> indiquer forward ou backward.
> 
> Est alors expliqué que direction=* est utilisé pour indiquer les points
> cardinaux si la signalisation n'est pas placée sur un chemin.
> 
> https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
> 
> 
> En toute logique, pour un stop, on devrait utiliser stop:direction=*,
> hors c'est direction=* qui est indiqué.
> Pas de points cardinaux pour les stops ?
> 
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop

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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Martin Koppenhoefer]

2017-10-27 10:19 GMT+02:00 Cascafico Giovanni :

> Ci sono 622 aeroway=waypoint nello spazio aerreo italiano, 1 in
> California e 2 in Australia. Al resto del mondo pare non interessino.
> Visto in nostro numero non esiguo, a suo tempo era stato discusso un
> import?



Innanzitutto ben ritrovato David!

Concordo con Giovanni, ci sono vari aspetti. Si tratta chiaramente di un
import, e non era stato ne discusso (se non sbaglio), ne fatto secondo le
regole (che già c'erano all'epoca, anche se nel dettaglio ancora meno
mature). Non è una particolarità di questo import, in quei tempi tanti
importavano senza rispettare le regole, sopratutto quando la quantità di
dati era tale da non creare attenzione.

Si tratta di pochi dati, che però, come dimostra l'utente Lola Fox, hanno
già creato confusione e tendono a farlo, perché si riferiscono a qualcosa
non osservabile e senza riferimento a terra. I dati del airspace e delle
aerovie non sono osservabili o verificabili sennò con dati ufficiali, e
perciò il contributo che un mappatore OSM può dare a questi dati è zero
(non c'è potenziale di miglioramento attraverso la "crowd", la versione
ufficiale non è "toccabile", i dati non hanno grandissima utiltà per farne
una eccezione (come nel caso dei confini politici), OSM sarebbe soltanto un
mezzo per distribuirli).

In generale, lo stato sui dati del airspace è di mappare le infrastrutture
(radio fari ecc.) ma non i limiti legali / astratti come airspace, aerovie,
ecc. perché si tratta di dati per specialisti, non migliorabili, non
osservabili, estesi e quindi "disturbano" e "confondano" (meno pertinente
per i punti di cui parliamo qui, ma la logica suggerirebbe di aggiungere
anche le aree come passo successivo, no?).

Io sarei per togliere, visto che sono, come lo dice anche David, puramente
"virtuali".

Visto che sono pochi punti, potrei anche tolerarli, ma formalmente non sono
da tenere.

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

Re: [OSM-talk-fr] Directions signalisations verticales

[François Lacombe]

Bonjour Axelos,

Je serais plutôt d'avis d'utiliser traffic_signals:direction sur tous les
panneaux routiers pour indiquer la direction du trafic impactée.
Si le panneau stop est cartographié à sa position réelle, direction=*
s'applique.

D'un point de vue perso, je cartographie les panneaux physiques à leur
position réelle que dans c'est possible, et leurs effets sur la highway (ou
sur ses noeuds)


A+

François

Le 27 octobre 2017 à 11:03, Axelos  a écrit :

> Coucou,
>
> J'ai dessellé une contradiction en ce qui concerne l'indication de la
> direction concernant les signalisations verticales (feux, stop
> cédez-le-passage)
>
> En effet, si on prend l'exemple du feu de signalisation, on nous demande
> d'utiliser le préfixe traffic_signals devant le tag direction pour y
> indiquer forward ou backward.
>
> Est alors expliqué que direction=* est utilisé pour indiquer les points
> cardinaux si la signalisation n'est pas placée sur un chemin.
>
> https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction
>
> En toute logique, pour un stop, on devrait utiliser stop:direction=*,
> hors c'est direction=* qui est indiqué.
> Pas de points cardinaux pour les stops ?
>
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop
>
> Cordialement.
>
> --
>
> Comment les entreprises surveillent notre quotidien ?
> https://frama.link/8XtqSFYU
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Woods vs Forests

[Dave F]

You appear to be differentiating based on size & location which, seeing 
OSM's output is visual & geospatial seems unnecessary.


*All* groups of trees are 'natural' so there should only be one primary 
tag. All "purposes" should be within sub-tags.


DaveF

On 27/10/2017 08:52, Tomas Straupis wrote:

Some info on how/why forest/wood tagging is used in Lithuania. I will
not give specific tags (forest vs wood, landuse vs natural etc),
because in my opinion that is a secondary issue. Let's say we have
tags F1 and F2.

F1 is for general forests. Those are the ones depicted on small scale
maps (full country/region).

F2 is for small wooded areas INSIDE other polygons, usually inside
residential, commercial, industrial zones.

This approach ignores utility as such (managed, non managed, natural,
left for full nature cycles as mention in Oleksiy's post). This
information could be added as a sub-tag if needed for some thematic
maps or specific statistical calculations.

What I'm saying is that maybe we should:
1. first decide the PURPOSES of having "tree cluster" polygons tagged
separately.
2. Then PRIORITISE the purposes (based on ACTUAL usage ignoring all
"it could theoretically be used to/for...")
3. and then decide which info goes to primary tag, which goes to
secondary tag(s).
4. And only THEN decide on actual tags (keys, values).
Doing it the other way round will take us back to this forest
discussion as it has been here for the last ten years like discussing
what the words "forest", "wood", "natural", "landuse", "landcover"
etc. actually mean.




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


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

Re: [OSM-talk] Woods vs Forests

[Daniel Koć]

W dniu 27.10.2017 o 08:36, Warin pisze:


The landuse key is clearly to tag the use of the land by humans.


It's also to indicate use of the water, hence it's not 100% clear and I 
understand why some people don't like it.


The natural key is unclear - it seams to be for both things made by 
nature and things made by man! To me this confused all and the key 
should be discouraged.
It should be replaced by the keys landcover and landform, these have 
no implication of human or nature but simply describe the type of 
feature.


Let's look at natural=tree - it doesn't matter if the tree was seeded by 
man or by natural means, the tree is natural object, which was not 
created by man (even GMO is about _modyfying_, not creating). There can 
be however man_made=tree - we have a popular artwork in Warsaw, which is 
a palm made of plastic (tagging has changed, but it's a nice example):


https://en.wikipedia.org/wiki/Greetings_from_Jerusalem_Avenues
https://www.openstreetmap.org/node/1795659661

Landcover is neutral (what one can see on the surface). I like it 
because it's closest to the "ground truth", and is very useful when we 
don't know more details. However we could promote "surface" tag as a 
primary and it would also make sense for me (currently it's defined as 
additional tag: "used to provide additional information about the 
physical surface of roads/footpaths and some other features").


I have no idea what "landform" can be, so I don't have an opinion on that.

However "natural" key for trees ( 
https://taginfo.openstreetmap.org/tags/natural=trees maybe?) sounds 
perfectly valid for me.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [Talk-it] Riseria

[Simone Saviolo]

Il giorno 27 ottobre 2017 11:11, Volker Schmidt  ha
scritto:

> Come taggare una riseria?
> Ho incontrato e mappato questa riseria [1] e ho utilizzato un tagging
> provvisorio di mia invenzione dopo non aver trovato niente via taginfo e
> wiki.
> Qualcun altro ha gia mappato una riseria (rice mill)?
>
> [1] https://www.openstreetmap.org/way/230014439
>

Secondo me (vercellese, nato e cresciuto nel riso :) ma non agricoltore, né
agronomo) una riseria è a tutti gli effetti una fabbrica: prende una
materia prima (risone) e la trasforma (raffina) in un prodotto rivendibile
(riso, ma anche la pula e la lolla che vanno ad altri trasformatori per
farne concime o combustibile - o borse e magliette, visto come funziona
oggi).

Per prima cosa, quindi, userei landuse=industrial su tutta l'area, con il
nome della riseria. I singoli edifici potrebbero eventualmente essere
building=industrial. Quanto ad un tag specifico per il fatto che è una
riseria, userei industrial=rice_mill sulla stessa way di
landuse=industrial.

Insomma, ricapitolando:

landuse=industrial
industrial=rice_mill
name=Riseria Pippo

industrial=rice_mill è già usato, anche se solo in due sole occasioni [2]

Ciao,

Simone

[2] https://taginfo.openstreetmap.org/keys/industrial#values
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Hiérarchie des relations d’itinéraire cyclistes

[Axelos]

Coucou,

Le 07/10/2017 à 20:33, Adrien Grellier a écrit :
> J'ai procédé de la même manière pour l'Euro-vélo 1, qui inclut le Canal
> de Nantes à Brest, et l'Euro-vélo 6, qui inclut la Loire à Vélo.
> 
> Il me semble que c'est une bonne manière de procéder, simple et qui
> évite là duplication de données. En plus ça respecte totalement l'esprit
> des grands circuits, qui se reposent en pratique sur les tracés plus locaux.


Merci pour ton retour.
J'ai donc mis en pratique cette logique sur deux véloroutes, dont la
seconde que partiellement, et depuis j’attends les retours pour éviter
des guerres d’éditions.

On m'a remonté l'info que OpenCycleMap n'affiche pas les routes
internationales, après vérification je confirme et j'ai demandé la cause
à Thunderforest par courriel (au cas où il s'agit d'un simple oublie).

À plus.

-- 

Comment les entreprises surveillent notre quotidien ?
https://frama.link/8XtqSFYU

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

[Talk-it] Riseria

[Volker Schmidt]

Come taggare una riseria?
Ho incontrato e mappato questa riseria [1] e ho utilizzato un tagging
provvisorio di mia invenzione dopo non aver trovato niente via taginfo e
wiki.
Qualcun altro ha gia mappato una riseria (rice mill)?

[1] https://www.openstreetmap.org/way/230014439
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] Woods vs Forests

[Warin]

On 27-Oct-17 06:52 PM, Tomas Straupis wrote:

Some info on how/why forest/wood tagging is used in Lithuania. I will
not give specific tags (forest vs wood, landuse vs natural etc),
because in my opinion that is a secondary issue. Let's say we have
tags F1 and F2.

F1 is for general forests. Those are the ones depicted on small scale
maps (full country/region).
Topology: They cannot overlap with other general landuse polygons:
water, reservoirs, riverbanks, meadows, scrub, sand, residential,
commercial, industrial zones etc.
Usage:
cartography: when generating small scale map we get a topologically
correct mosaic - non overlapping polygons - we do not have to worry
about overlapping polygons, draw order.
statistics: used to calculate percentage of forest coverage for a region

F2 is for small wooded areas INSIDE other polygons, usually inside
residential, commercial, industrial zones.
Topology: They MUST be above (fully inside) residential, commercial or
industrial polygon. If the F2 forest area is too large to be included
in say residential area - change it to F1.
Usage:
cartography: ignored for small scale maps. for large scale maps
(detailed small area) they are drawn on top of residential, commercial
and industrial areas.
statistics: ignored when calculating percentage of forest coverage.

This approach ignores utility as such (managed, non managed, natural,
left for full nature cycles as mention in Oleksiy's post). This
information could be added as a sub-tag if needed for some thematic
maps or specific statistical calculations.

What I'm saying is that maybe we should:
1. first decide the PURPOSES of having "tree cluster" polygons tagged
separately.
2. Then PRIORITISE the purposes (based on ACTUAL usage ignoring all
"it could theoretically be used to/for...")
3. and then decide which info goes to primary tag, which goes to
secondary tag(s).
4. And only THEN decide on actual tags (keys, values).
Doing it the other way round will take us back to this forest
discussion as it has been here for the last ten years like discussing
what the words "forest", "wood", "natural", "landuse", "landcover"
etc. actually mean.



In; F1 there are the words "general landuse polygons"

F2 there are the words "residential, commercial, industrial zones" that clearly 
imply land use.

So your discussion is clearly about land use? Fine - that is ok.

I have an area that is used for recreation - picnics, walks, etc. It is a designated 
"National Park".
So human land use is 'recreation'. There are native animals in there .. but the 
plan of management is primarily for 'recreation' and has been for many decades.

Some of the area is grassed, some trees ... but the human use of the land is 
not 'grass' nor 'trees', but 'picnic', 'walks' and 'peace and quite'.

At the moment there is no declared landuse tag on this area, it does have a 
admin boundary for the National Park, which could also in this case be used for 
the land use. It does have separately tagged land covers of paved, unpaved, 
trees, grass and water. But the single land use should be recreation.

As the 'use' is separate from 'cover' these things should be considered 
separately.




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

[OSM-talk-fr] Directions signalisations verticales

[Axelos]

Coucou,

J'ai dessellé une contradiction en ce qui concerne l'indication de la
direction concernant les signalisations verticales (feux, stop
cédez-le-passage)

En effet, si on prend l'exemple du feu de signalisation, on nous demande
d'utiliser le préfixe traffic_signals devant le tag direction pour y
indiquer forward ou backward.

Est alors expliqué que direction=* est utilisé pour indiquer les points
cardinaux si la signalisation n'est pas placée sur un chemin.

https://wiki.openstreetmap.org/wiki/Key:traffic_signals:direction

En toute logique, pour un stop, on devrait utiliser stop:direction=*,
hors c'est direction=* qui est indiqué.
Pas de points cardinaux pour les stops ?

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop

Cordialement.

-- 

Comment les entreprises surveillent notre quotidien ?
https://frama.link/8XtqSFYU

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

[OSM-talk-be] workshop on using qgis with osm data

[joost schouppe]

Hi,

At the last Leuven meetup, Jo organized a workshop about using QGIS with
OSM data to render nice maps.

We also looked at using Maperitive, which seems excellent for rendering
maps-for-print if you don't really need to process data but just render it
as is.

The two presentations on QGIS are available here:

https://github.com/osmbe/qgis_rendering/

Thank you to all the people making this happen. We would like to something
similar in Brussels, where it should be easier to form a bigger group. If
you have a suggestion for a topic, please shoot.

-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Cascafico Giovanni]

Ci sono 622 aeroway=waypoint nello spazio aerreo italiano, 1 in
California e 2 in Australia. Al resto del mondo pare non interessino.
Visto in nostro numero non esiguo, a suo tempo era stato discusso un
import?

Il 27 ottobre 2017 06:55, Andreas Lattmann 
ha scritto:
>>Io sarei per tenerli, secondo me sono mappati in modo chiarissimo.
>
> Anch'io sono per tenerli.
>
> Andreas Lattmann
> --
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it

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

Re: [OSM-talk-fr] Rapprochement Bano

[Christian Quest]

Le 27 octobre 2017 à 04:56, Francois Gouget  a écrit :

> Le jeudi 26 octobre 2017 à 10:45 +0200, Christian Quest a écrit :
> > Les applis qui ont besoin d'adresses peuvent utiliser celles d'OSM et
> > compléter avec d'autres sources (BANO en est une).
> [...]
> > On va aussi pouvoir bien mieux exploiter les données du cadastre dans
> > un avenir très proche, vu qu'on a accès depuis quelques semaines aux
> > données EDIGEO brutes. Donc je patienterai un peu pour voir ce qu'on
> > peut faire de mieux que ce qui a été fait jusque maintenant avec les
> > extractions faites uniquement à partir de fichiers PDF sur
> > cadastre.gouv.fr
>
> Donc ce que je retiens :
> * Priorité aux noms de rues.
>   Tout à fait d'accord. Mais c'est pas évident de contribuer si on
> n'est pas sur place. Quelles sont vos techniques ?
>

Le rendu BANO permet de se faire une très bonne idée dans la majorité des
cas.


  A-t-on une idée du temps que vont prendre les 16 dernières voies
> ? Si elles restent c'est qu'il n'y a pas de contributeur dans ces
> villes ?
>

Le rythme s'est pas mal ralentit ces derniers temps. Si on s'y remet
sérieusement comme au début de la dispo de BANO, ces 160.000 voies peuvent
quasi disparaitre d'ici un an. Bien sûr, il y aura un résidu qui résistera
sur les cas tordus et particuliers qui nécessitent d'aller sur le terrain.


  Enfin, si on arrive effectivement au bout de cet aspect, je pense que
> ça a du sens de revisiter comment va s'organiser la suite.
>
> * Attendre voir si on peut mieux faire avec le nouveau cadastre.
>   Mieux = import massif ? Points "adresse manquante" dans Osmose ? (20
> millions de points ça va être joli ;-)
>
>
Le mieux c'est un peu plus d'adresses et peut être un meilleur calage
géographique.

* En l'absence d'import massif alors on continue avec une intégration
> manuelle qui prendra 10 à 15 ans.
>

L'import massif n'est pas souhaitable de mon point de vue ou alors c'est
qu'on privilégie la quantité à la qualité, et je ne suis pas pour.

  Peut-on déveloper des stratégies pour maximiser le rendement des
> efforts d'intégration ?
>   - Par exemple si un contributeur ajoute un commerce / restaurant et
> pointe vers son site web, il aura probablement vu son adresse quelque
> part. Donc on pourrait recommander l'ajout de l'adresse dans les pages
> Wiki de amenity, shop et office. Mais cela fera quelques rues
> commerçantes avec plein d'adresses et pas grand chose ailleurs.
>

Ouille... tout comme un bâtiment n'a pas de lien 1/1 avec une adresse, un
commerce n'a pas de lien 1/1 non plus.
Il est préférable de mettre son adresse en contact:*=*, l'adresse est un
objet à part entière.

Ces adresses en contact:* sont de toute façon exploitables si on en a
besoin, mais au moins on sait que ce n'est pas l'adresse elle même qu'on a
renseigné.


  - Ajouter les adresses aux intersections. Je pense qu'avoir ces
> données dans OSM serait presque suffisant pour les usages courants.
> Mais pour un contributeur ce n'est pas le cas le plus simple à traiter
> : à chaque fois la question se pose de savoir sur quelle rue est le
> numéro. Aussi, un contributeur gagne-t-il en temps à se concentrer sur
> les intersections ?
>

J'avais commencé comme ça sur ma commune, avec des interpolations. A
l'époque le plan cadastral était en image et pas vectoriel.
J'ai ensuite remplacé ces interpolations par les points adresse (toujours à
partir du plan image).

Qu'on ajoute les points ou qu'on mette des interpolations, la question
reste la source: terrain ou pas, donc amélioration/contrôlé ou juste copie
d'une source (le cadastre dans la majorité des cas).

  - Ajouter une adresse par rue bordant un paté de maison. Là on évite
> le problème des intersections mais on répond un peu moins bien à la
> question "je tourne à droite ou à gauche ?".
>   - Se concentrer sur les rues couvertes par Mapillary. Ca permet de
> gagner du temps et de couvrir une zone plus étendue en évitant d'avoir
> à aller sur place. Mais la couverture Mapillary est très loin d'être
> complète mais j'ai l'impression qu'assez peu de numéros sont lisibles
> et donc si je compte le temps passé à chercher une image où un numéro
> est lisible je ne suis pas sûr que le rendement soit si bon.
>
>
Il faudrait des photos latérales... or c'est souvent des photos frontales
qui sont prises et versées et oui, ça prend un temps fou.


* Les outils peuvent s'appuyer sur la BANO.
>   Si on table sur une intégration qui prend 10 ans ou plus alors
> effectivement les outils ont plutôt intérêt à ajouter du support pour
> la BANO afin d'être utilisables. Mais dans ce cas il faudrait les en
> informer clairement.
>   Ca veut aussi dire qu'ils devront intégrer du code spécifique pour la
> France, soit au niveau de l'outil même, soit au niveau de la
> préparation des fichiers OSM qu'ils utilisent en faisant leur propre
> 'import massif' de la BANO.
>
>
Non, ce n'est pas du code spécifique pour la France, c'est du code
spécifique pour les 

Re: [OSM-talk] Woods vs Forests

[Tomas Straupis]

Some info on how/why forest/wood tagging is used in Lithuania. I will
not give specific tags (forest vs wood, landuse vs natural etc),
because in my opinion that is a secondary issue. Let's say we have
tags F1 and F2.

F1 is for general forests. Those are the ones depicted on small scale
maps (full country/region).
Topology: They cannot overlap with other general landuse polygons:
water, reservoirs, riverbanks, meadows, scrub, sand, residential,
commercial, industrial zones etc.
Usage:
cartography: when generating small scale map we get a topologically
correct mosaic - non overlapping polygons - we do not have to worry
about overlapping polygons, draw order.
statistics: used to calculate percentage of forest coverage for a region

F2 is for small wooded areas INSIDE other polygons, usually inside
residential, commercial, industrial zones.
Topology: They MUST be above (fully inside) residential, commercial or
industrial polygon. If the F2 forest area is too large to be included
in say residential area - change it to F1.
Usage:
cartography: ignored for small scale maps. for large scale maps
(detailed small area) they are drawn on top of residential, commercial
and industrial areas.
statistics: ignored when calculating percentage of forest coverage.

This approach ignores utility as such (managed, non managed, natural,
left for full nature cycles as mention in Oleksiy's post). This
information could be added as a sub-tag if needed for some thematic
maps or specific statistical calculations.

What I'm saying is that maybe we should:
1. first decide the PURPOSES of having "tree cluster" polygons tagged
separately.
2. Then PRIORITISE the purposes (based on ACTUAL usage ignoring all
"it could theoretically be used to/for...")
3. and then decide which info goes to primary tag, which goes to
secondary tag(s).
4. And only THEN decide on actual tags (keys, values).
Doing it the other way round will take us back to this forest
discussion as it has been here for the last ten years like discussing
what the words "forest", "wood", "natural", "landuse", "landcover"
etc. actually mean.

-- 
Tomas

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

Re: [OSM-talk] Woods vs Forests

[Warin]

On 27-Oct-17 04:51 PM, Oleksiy Muzalyev wrote:

On 27.10.17 00:49, Dave F wrote:

[...]
I think you'd be hard pressed to find any area of trees which hasn't 
been managed in one way or another by humans; especially in the 
Western world. [...]


There is a theory nowadays that woods should be left alone to natural 
cycles which may last hundreds of years. At least that a forest is not 
a park where everything should be cleaned up and tidy. Dead wood in a 
forest is the food for numerous insects. These insects are the basis 
of a biodiversity pyramid. Here is some information on it: 
http://blogs.helsinki.fi/deadwoodmeeting/files/2016/02/Barbalat_dead-wood-insects_web.pdf


Best regards,

O.


For thousands of years the Australian Aborigines have used fire to 
manage their lands.
There is a view that current fire dangers in Australia are a result of 
the lack of regular fire burning practices.
There is also the view that these burning practices encourage native 
vegetation.
And yet another view that these burning practices would discourage 
introduced weeds.
There are many who want regular patterned fire burns conducted for the 
above reasons.


Having said that, there are at several areas that have not been managed 
by humans by fire for many, if not thousands of, years - one where the 
Wollemi Pine was found and a few where cycads remain in central and 
northern Australia.


--
My view;

The landuse key is clearly to tag the use of the land by humans.

The natural key is unclear - it seams to be for both things made by 
nature and things made by man! To me this confused all and the key 
should be discouraged.
It should be replaced by the keys landcover and landform, these have no 
implication of human or nature but simply describe the type of feature.



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