Re: [Talk-it] tag stazione arrivo/partenza impianti di risalita

[solitone via Talk-it]

On 19 Jun 2019, at 22:17, Martin Koppenhoefer  wrote:
> 
> Il giorno 19 giu 2019, alle ore 18:25, Marco  ha 
> scritto:
>> leggendo https://wiki.openstreetmap.org/wiki/Tag:aerialway%3Dstation non 
>> vedo nessun suggerimento ad usare aerialway=yes + public_transport=station
> 
> Sempre in ogni caso direi che una modifica (incompatibile, nel senso che non 
> si può fare tutt’e due) del genere da un tag di 27000 utilizzi ad uno poco 
> usato (aerialway=yes senza guardare le combinazioni con o senza station, 
> 1100) meriterebbe una discussione con gli altri e non dovrebbe essere fatta 
> da solo (per esempio fa sparire le stazioni dalle mappe, o no?).

Vista la quantità di oggetti mappati con con aerialway=station e che in più 
pagine della wiki (un altro esempio: [1]) si indica questo approccio per le 
stazioni, io continuerò a mappare con aerialway=station, come ho sempre fatto 
finora. Non vedo il vantaggio di seguire il suggerimento di [2], che dice:

> Cable-cars, drag-lifts and chair-lifts can be modeled using aerialway=*. 
> These can be considered as a form of public transport in that they are 
> shared, operated for fixed times of day at predictable intervals. Some cable 
> cars may operate to a clock-face timetable.
> 
> Aerialway stations are often tagged as aerialway=station. You can add 
> public_transport=station, public_transport=stop_position and aerialway=yes.

In particolare, benché si possa valutare se aggiungere public_transport=station 
e public_transport=stop_position per gli impianti che trasportano persone 
(molti), non mi convince affatto la sostituzione di aerialway=station con 
aerialway=yes. Sono quindi d’accordo con Martin.

[1] https://wiki.openstreetmap.org/wiki/Piste_Maps
[2] https://wiki.openstreetmap.org/wiki/Public_transport
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Il DB di Geofabrik

[aldoct]

OT: Frequento anche il tuo sito e ho scaricato il file sicilia.tar.gz; dopo
averlo scompattato, con GMAPTOOL, ho cercato di estrarre il file TYP per
modificarne la visualizzazione ma non l'ho trovato. Puoi spiegarmi come mai?
Saluti



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

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

Re: [OSM-talk] Proposed mechanical edit - addition of office=diplomatic to amenity=embassy with country=*

[Warin]

The need for a replacement of amenity=embassy was explained in the approved 
office=diplomatic proposal.

By doing a mechanical edit the work load of mappers is reduced, I would think 
50%, and the adoption of the new tag promoted by its evident use.

I missed that office=diplomatic was required with diplomatic=* edits I did some 
time ago. I think others have done the same.

The use of diplomatic=* has outstripped office=diplomatic even ignoring the 
starting offset due to previous use before the accepted proposal.

The tagging of diplomatic=* at the moment has little motivation as it is not 
rendered by many.
Most use the one rendering symbol for all of them.
Determining 'embassy' could be done to some extent by location, in a countries 
capitol city, and by the name containing 'embassy'.
Determining 'consulate' could be done in a similar manner - outside the capitol 
city and containing 'consulate'.
There will be exceptions! For these reasons I am not advocating it.
I am reluctant to suggest the mechanical addition of office=diplomatic to 
diplomatic=* due to the past use of the tag and the more numerous 
amenity=embassy which was the original motivation for the accepted proposal.



On 19/06/19 21:41, Joseph Eisenberg wrote:

I've spent several hours creating wiki pages for the new, approved
tags from this proposal, so I'm in favor of the tags, even
office=diplomatic (which doesn't seem much of an improvement, compared
to the others).

But I'm not convinced that adding the office=diplomatic tag to
existing features is very helpful. It would be more useful to add
diplomatic=embassy/consulate/liaison and the additional subtags to
show the precise type of embassy or consulate or other diplomatic
facility, but this probably requires local survey or at least
extensive searching of web pages for every feature.

On 6/19/19, Frederik Ramm  wrote:

Hi,

On 18.06.19 03:21, Warin wrote:

Following the successful proposal of introducing office=diplomatic to
eventually replace the amenity=embassy (which is used to not only tag
embassies but other diplomatic service) I am proposing to add the
approved tag office=diplomatic to all instances that have both the tag
amenity=embassy with the tag country=*.

I don't think that this is necessary or helpful. When office=diplomatic
was "approved", we did not discuss a mass addition to existing features.
This is something that time can solve, we don't need an automatic edit
for it.

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


___
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: [Talk-GB] SuDS (Sustainable Urban Drainage Systems)

[Warin]

The area I would tag as a landuse=basin, 
basin=detention/retension/infiltration. That is what I have done around me.
Most of these are larger than your example, the largest one that I know 
of is https://www.openstreetmap.org/way/282846991.


Some sports field are used as a detention pond when high rates of rain 
fall cause the drainage system to back up, the over flow is held by the 
low lying sports field for later drainage. I have left these alone - a 
temporary use that won't often be seen I hope.


On 20/06/19 00:09, Jez Nicholson wrote:
My client GeoSmart are experts on SuDS, further reading at 
https://geosmartinfo.co.uk/knowledge-hub/sustainable-drainage-systems/


Many/most planning applications for new developments now have to 
mitigate the drainage area that has been lost to 
houses/drives/roads/etc. It can be difficult to identify a SuDS 
installation as they are deliberately blended into the site. It might 
just be a pond at the bottom of a larger dipped area that'll take some 
of the bite out of a flash flood.




On Wed, Jun 19, 2019 at 2:46 PM SK53 > wrote:


Last night before visiting the pub we had a look at part of
Sheffield's "Grey-to-Green" SuDS system. Unfortunately all my
batteries ad packed up at this point, but there are some decent
pictures on twitter
.
The bit we looked at was outside the courthouses. It consisted of :

  * A bio-swale. Planted with a colourful mixture of plants most
of which I've forgotten now, although I do recall Jerusalem
Sage. The ground was a gravel mix with presumably a
geo-membrane underneath to retain water. A few birches were
also planted along the length of the swale. Superficially this
just looks from a distance like a large ornamental flower bed.
  * Concrete 'dams' periodically, along the swale, rising to
within a few inches of pavement level and with a v-shaped
notch in the centre. Obviously these are not really dams, more
a type of weir, being designed to moderate the flow of water
through pooling behind each dam. I've seen similar
constructions in the Alps albeit on a larger scale.
  * At the bottom of the swale a more obvious drainage channel.
Where the swale is broken for pedestrian access this runs in a
recessed gutter covered by a grille.

There are probably other features of the completed scheme which we
didn't see. I notice many new-build housing estates will have an
area set aside as a water retention basin.

I've previously noted a SuDS along Ribblesdale Road


in Nottingham, but the features involved are on too small a scale
to consider mapping for now.

This type of infrastructure is becoming much more popular,
particularly with extreme flooding events due to surface run-off.
I'd hoped to look at the one in Sheffield, and fortunately Laura
both remembered this and where it was. Larger ones are relatively
simple to map the main features, choosing viable & appropriate
tags is more challenging. I've had a go
, but am
very open to other suggestions. I suspect the whole swale should
be mapped as a waterway feature. For now I've used waterway=drain
with intermittent=yes for the channel in the swale & the
connecting part of the drain running in a covered gutter (one
import in Santa Clara Co, CA opted for waterway=stream). However
many of the features could use man-made rather than waterway tags.

In conclusion: there's probably a SuDS near you; they're hard to
tag (for know); but not too hard to map; we could do with thinking
about better tags.

Regards,

Jerry


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



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



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

Re: [Talk-us] WikiProject United States Public Lands

[Kevin Kenny]

I surmise that Steve intended to include a link:
https://wiki.openstreetmap.org/wiki/WikiProject_United_States_Public_Lands

On Wed, Jun 19, 2019 at 6:34 PM stevea  wrote:
>
> I have burnished this wiki to attempt to be comprehensive with Public Lands 
> at federal, state, and county levels (even a bit city-, though here we blur 
> with leisure=park).  Much of what is here mimics 
> https://wiki.osm.org/wiki/Tag:boundary%3Dprotected_area#Protect_classes_for_various_countries
>  United States' row, though much more comprehensively:  i.e. the Public Lands 
> wiki doesn't include simply a number-value for the protect_class key, it 
> tries to describe ALL of the tags Public Lands should receive in the USA.
>
> It is quite likely I've missed some federal-level (some "park-like," some 
> likely not) Public Lands, though it's also possible all are listed.  If you 
> have comprehensive knowledge of the many categories of (federal, especially) 
> Public Lands, please take a look at this wiki and see if it is or isn't 
> comprehensive / complete.  You might also agree or disagree with the tagging 
> schemes that are there, feel free to edit them if you disagree, they are sort 
> of "wet ink."
>
> Thank you,
> SteveA
> California
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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

[Talk-us] WikiProject United States Public Lands

[stevea]

I have burnished this wiki to attempt to be comprehensive with Public Lands at 
federal, state, and county levels (even a bit city-, though here we blur with 
leisure=park).  Much of what is here mimics 
https://wiki.osm.org/wiki/Tag:boundary%3Dprotected_area#Protect_classes_for_various_countries
 United States' row, though much more comprehensively:  i.e. the Public Lands 
wiki doesn't include simply a number-value for the protect_class key, it tries 
to describe ALL of the tags Public Lands should receive in the USA.

It is quite likely I've missed some federal-level (some "park-like," some 
likely not) Public Lands, though it's also possible all are listed.  If you 
have comprehensive knowledge of the many categories of (federal, especially) 
Public Lands, please take a look at this wiki and see if it is or isn't 
comprehensive / complete.  You might also agree or disagree with the tagging 
schemes that are there, feel free to edit them if you disagree, they are sort 
of "wet ink."

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

Re: [Talk-at] fahrverbote in tirol

[Friedrich Volkmann]

On 19.06.19 21:56, Rainer Fügenstein wrote:

"Navis sollten Fahrverbote übernehmen

Der Ausweichverkehr soll mit Hilfe der Navis unterbunden werden, erklärte 
der Landeshauptmann. Die Fahrverbote seien bereits an das Innenministerium 
übermittelt worden, das wiederum den Navi-Betreibern die Verkehrsdaten zur 
Verfügung stellt."


Für so was (Ziel-/Quellverkehr) ist vehicle=destination übrigens gedacht 
(und nicht für Anrainerverkehr). Da aber nur an bestimmten Stellen 
Verbotsschilder stehen (bzw. Kontrollen stattfinden) und die Verbote zudem 
so schwammig sind, dass sogar die Polizei nur "mit dem nötigen 
Fingerspitzengefühl" entscheiden kann, wird sich das mit Tagging sowieso 
nicht lösen lassen, sondern nur mit in im den Routingengines hartcodierten 
Routingregeln. Ich schätze, dass OSM-basierte Router nicht die einzigen 
sind, die an dieser Aufgabe scheitern werden.


Jetzt können wir gespannt sein, ob das Innenministerium OSM oder 
OSM-nutzende Navianbieter (Osmand usw.) überhaupt kennt und ob über diesen 
Kanal die Informationen jemals an die Tiroler Mapper weitergeleitet werden.


Ich würde als Mapper jetzt erst mal gar nichts tun, denn erstens ist die 
Umsetzbarkeit sowieso fraglich (s.o.), zweitens ist der Wartungsaufwand 
hoch, und drittens ist der praktische Nutzen gleich null, da die Fahrverbote 
nur jenen ein Problem bereiten, die vom Navi wegen einer Stauwarnung auf 
eine Ausweichroute geschickt werden. OSM-basierte Navis können das noch gar 
nicht.


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

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

Re: [Talk-it] Il DB di Geofabrik

[Luca Delucchi]

Il mer 19 giu 2019, 18:52 aldoct  ha scritto:

> Penso anch'io. Ma, a proposito, non sei tu che cura la pubblicazione dei
> dati
> su ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/odbl/?
>

No mi spiace, io mantengo quello su geodati.fmach.it

Saluti, Aldo Sciacca
>

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

Re: [Talk-it] tag stazione arrivo/partenza impianti di risalita

[Martin Koppenhoefer]

per me si potrebbe aggiungere public_transport=station alle aerialway che 
trasportano persone e sono accessibili, ma non cambierei assolutamente 
aerialway=station in yes. 


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

Re: [Talk-it] tag stazione arrivo/partenza impianti di risalita

[Martin Koppenhoefer]

sent from a phone

> Il giorno 19 giu 2019, alle ore 18:25, Marco  ha 
> scritto:
> 
> Un mappatore a Livigno ha convertito tutte le stazioni precedentemente 
> mappate come aerialway=station , con aerialway=yes + 
> public_transport=station. É corretta questa seconda combinazione?
> 
> leggendo https://wiki.openstreetmap.org/wiki/Tag:aerialway%3Dstation non vedo 
> nessun suggerimento ad usare aerialway=yes + public_transport=station
> 
> la descrizione di public_transport=station 
> https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstation invece a 
> me sembra non specificare nulla.



io non ci credo molto in public_transport=station 
al meno per le fermate degli autobus lo trovo una complicazione inutile. 
A questo punto, se nemmeno per gli autobus, che senso potrebbe avere cambiare 
il tagging per le aerialway ;-)

In ogni caso penso ci sia una differenza di significato nel caso degli 
aerialway, perché station=aerialway non ha implicazioni quanto potrebbe essere 
pubblico o meno (anzi è specificato anche per trasporto merci), mentre 
public_transport è solo per trasporto pubblico (questo potrebbe essere a favore 
della modifica o anche no)

Sempre in ogni caso direi che una modifica (incompatibile, nel senso che non si 
può fare tutt’e due) del genere da un tag di 27000 utilizzi ad uno poco usato 
(aerialway=yes senza guardare le combinazioni con o senza station, 1100) 
meriterebbe una discussione con gli altri e non dovrebbe essere fatta da solo 
(per esempio fa sparire le stazioni dalle mappe, o no?).

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

[Talk-at] fahrverbote in tirol

[Rainer Fügenstein]

https://tirol.orf.at/stories/3001188/

zitat:

"Navis sollten Fahrverbote übernehmen

Der Ausweichverkehr soll mit Hilfe der Navis unterbunden werden, 
erklärte der Landeshauptmann. Die Fahrverbote seien bereits an das 
Innenministerium übermittelt worden, das wiederum den Navi-Betreibern 
die Verkehrsdaten zur Verfügung stellt."


falls das für OSM noch niemand gemacht haben sollte.

mfg

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

[Talk-at] Fwd: AGIT: YouthMappers Workshop

[Markus Mayr via Talk-at]

Hallo, Leute!

Seht euch die angehängte Nachricht von Jakob an, wenn ihr an der
Teilnahme/Gründung eines internationalen OSM Youth-Mapper Netzwerkes
interessiert seidt.
Dazu gibt es zwei Workshops auf der AGIT 2019 in Salzburg.

Beste Grüße,
Markus (ScubbX)



 Weitergeleitete Nachricht 
Betreff:AGIT: YouthMappers Workshop
Datum:  Wed, 19 Jun 2019 10:00:04 +0200
Von:Jakob Miksch 
An: markusm...@gmx.net



Hallo Markus,

noch eine Sache: Am Freitag der AGIT veranstalten wir(Maptime Salzburg)
in Kooperation mit der Uni Heidelberg und der Uni Warwick einen OSM
Mapathon und anschließend ein Treffen mit dem Ziel ein europäisches
Netzwerk für YouthMapping Gruppen zu gründen. Hier die Links zu den 
beiden Sessions.
https://www.conftool.com/giweek2019/index.php?page=browseSessions_session=65
https://www.conftool.com/giweek2019/index.php?page=browseSessions_session=66

Die ursprüngliche Initiative kam dabei aus Heidelberg. Potentielle
Mitglieder dieses neuen Netzwerks wären dann: Disaster Mappers
Heidelberg, Uni Warwick, Polymappers Milano, CartoNG Frankreich, Maptime
Salzburg.

Falls das für dich oder euch in Wien interessant ist, seid ihr herzlich
eingeladen da mitzuwirken oder einfach nur dran teilzunehmen. So wie ich
es verstehe soll es einfach darum gehen einen europäischen Austausch
über OSM-Mapathons zu initiieren. Du kannst das natürlich auch gerne
weiterleiten. Bei Fragen gerne melden :-)

Viele Grüße,
Jakob
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk-be] nieuwe-fiets-en-voetgangerstunnel-in-ekeren

[Tim Couwelier]

Karel,

het is HIER te doen:
https://www.openstreetmap.org/way/31647365#map=16/51.2843/4.4347=N

https://assets.antwerpen.be/srv/assets/api/download/28cef7be-5225-474e-93ff-8d67322be61f/plan_tunnel.pdf
is wat er zou moeten uitgevoerd zijn.

En voor wie houdt van wat info over hoe ze zo'n tunnel daar onder schuiven:
https://www.antwerpen.be/nl/info/5610f78bcaa8a762cd8b4567/bouw-van-een-fietstunnel

Op wo 19 jun. 2019 om 20:12 schreef Karel Adams :

> cfr.
>
> https://www.vrt.be/vrtnws/nl/2019/06/19/nieuwe-fiets-en-voetgangerstunnel-in-ekeren-geopend/
>
> Ofwel kijk ik op de verkeerde plaats, ofwel is deze tunnel nog helemaal
> niet ingetekend in OSM? Wie wie wie?
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-pt] Voluntários para administrador da lista

[f . dos . santos]

Sim, somos os 3 que temos a chave de administração.

- Mail original -
From: "topolusitania via Talk-pt" 
To "Lista de discussão para Portugal" 
Cc: topolusita...@yahoo.com
Sent: Mercredi 19 Juin 2019 20:35:29
Subject: Re: [Talk-pt]  Voluntários para administrador da lista



Olá 

Relendo mails antigos (de 2014): 

Quem é o actual administrador da mailing list ? 
O Filipe Roque chegou a passar o "poder" ? 
Cumprimentos 
TopoLusitania 

Voluntários na altura: 
 
 
 


[Talk-pt] voluntários para administrador da lista 
Jun 26, 2014 at 12:18 AM 

Filipe Roque  
To: Lista de discussão para Portugal  
Olá, 
Eu sou o original e ainda actual administrador desta lista do OSM. 
Queria reduzir o meu nível de participação no OSM, pelo que venho 
procurar candidatos para tomarem o meu lugar. 
Administrar a lista não tem dado nenhum trabalho. Interessados? 
cumprimentos, 
flip 



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

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

Re: [Talk-pt] Voluntários para administrador da lista

[topolusitania via Talk-pt]

 Olá

Relendo mails antigos (de 2014):

Quem é o actual administrador da mailing list ?
O Filipe Roque chegou a passar o "poder" ?
Cumprimentos
TopoLusitania

Voluntários na altura:





[Talk-pt] voluntários para administrador da lista
Jun 26, 2014 at 12:18 AM

Filipe Roque 
To: Lista de discussão para Portugal 
Olá,
Eu sou o original e ainda actual administrador desta lista do OSM.
Queria reduzir o meu nível de participação no OSM, pelo que venho
procurar candidatos para tomarem o meu lugar.
Administrar a lista não tem dado nenhum trabalho. Interessados?
cumprimentos,
flip


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

[OSM-talk-be] nieuwe-fiets-en-voetgangerstunnel-in-ekeren

[Karel Adams]

cfr. 
https://www.vrt.be/vrtnws/nl/2019/06/19/nieuwe-fiets-en-voetgangerstunnel-in-ekeren-geopend/


Ofwel kijk ik op de verkeerde plaats, ofwel is deze tunnel nog helemaal 
niet ingetekend in OSM? Wie wie wie?




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

Re: [Talk-pt] Estuário do Tejo & linha de costa (Topo Lusitania)

[topolusitania via Talk-pt]

 De acordo.
Sugiro que prolongues a coastline no mínimo até à ponte de VF Xira, se bem que 
me parece que as marés vão um pouco mais acima -(Carregado ? Azambuja?)
Cumprimentos
TopoLusitania On Thursday, June 13, 2019, 2:44:03 PM GMT+1, Hugo Valentim 
 wrote:  
 
  
OK. Compreendi o histórico.

  
 
A coastline, de facto, é renderizada a partir de informação tratada em separado 
(osshapefiles publicamente disponíveis são supostamente actualizados a cada 12 
horas, não tenho a certeza se o openstreemap.org se actualiza com a mesma 
frequência…).

  
 
Ora, do meu ponto de vista, no instante actual, a vantagem em usar acoastline 
para demarcar o Estuário reside precisamente no facto de ela não ser, do ponto 
de vista da edição do mapa, um polígono. O único requisito para não a “quebrar” 
é manter uma linha contínua de segmentos, um procedimento automático existe < 
https://osmcode.org/osmcoastline/> que se encarrega de gerar os polígonos de 
“água” com o devido limite de 2000 pontos (em obediência à API v6) – por 
coincidência ou não gerando o mesmíssimo resultado doplugin Split do QGIS. 
Provavelmente os ficheiros  também poderão 
ser usados na geração de mapas para Garmin.

  
 
O uso dacoastline também admite a renderização do natural=shoal (áreas a 
descoberto na maré baixa, o que não sucede se a margem for definida como 
riverbank), embora em última análise isso seja uma especificidade do 
mapnik-carto.

  
 
Por outro lado, há ainda, por inerência, a questão da exclusão/inclusão (imagem 
inversa) nos polígonos da terra. A linha de água do Estuário do Tejo 
actualmente acaba em frente ao Cais do Sodré (Gargalo do Tejo).

  
 
Assim, no instante presente, talvez não fosse má ideia incorporar o Mar da 
Palha simultaneamente nacoastline e no multipolígono Iberian Peninsula?

  
 
Cump.s,

H. Valentim

  
 
  
 
De: talk-pt-requ...@openstreetmap.org
Enviado: 11 de junho de 2019 13:00
Para: talk-pt@openstreetmap.org
Assunto: Talk-pt Digest, Vol 113, Issue 4

Today's Topics:

   1. Re: Estuário do Tejo & linha de costa (Topo Lusitania Lusitania)
   2. Re: Estuário do Tejo & linha de costa (Topo Lusitania Lusitania)


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

[talk-cz] JOSM - tag2link RUIAN

[Petr Schönmann]

Ahoj,
nechal jsem přidat do pluginu tag2link proklik na webstránky RUIAN - detail
objektu. Když tedy nyní kliknete na klíč či hodnotu, nabídne vám menu volbu
která vás přesměruje na Veřejný dálkový přístup.

INFO viz tiket níže.
https://josm.openstreetmap.de/ticket/17828#ticket

Pěkný den.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-it] Il DB di Geofabrik

[aldoct]

Penso anch'io. Ma, a proposito, non sei tu che cura la pubblicazione dei dati
su ftp://ftp5.gwdg.de/pub/misc/openstreetmap/openmtbmap/odbl/? Mi sono
impelagato in questi meandri proprio perché il file mtbitaly.exe (che trovo
comodissimo) non era aggiornato da un bel po'. C'è qualche problema nel
sito?
Saluti, Aldo Sciacca



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

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

[Talk-it] tag stazione arrivo/partenza impianti di risalita

[Marco]

Ciao a tutti,

chiedo suggerimenti su quale sia la miglior combinazione per mappare le 
stazioni di partenza/arrivo degli impianti di risalita (skilift, 
seggiovie e cabinovie).


Un mappatore a Livigno ha convertito tutte le stazioni precedentemente 
mappate come aerialway=station , con aerialway=yes + 
public_transport=station. É corretta questa seconda combinazione?


leggendo https://wiki.openstreetmap.org/wiki/Tag:aerialway%3Dstation non 
vedo nessun suggerimento ad usare aerialway=yes + public_transport=station


la descrizione di public_transport=station 
https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstation 
invece a me sembra non specificare nulla.


consigli?

grazie

Marco


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

[Talk-gb-westmidlands] Swift Payzones .

[Andy Mabbett]

In our collaboration with Centro/ TfWM, have we mapped any of the
"Swift Payzones" (in shops; and kiosks in bus stations) and on-street
"Swift Collectors"? [1]

Neither of the two closest to my home seem to be mapped, and I'm
looking for a model of best practice - though if we could get TfWM to
add and maintain them, so much the better.


[1] See: https://www.networkwesmidlands.com/swift/topping-up/


-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk-fr] routage surfacique

[osm . sanspourriel]

Le 19/06/2019 à 14:34, Phyks - ph...@phyks.me a écrit :


Je mets volontairement de côté une place aussi complexe que
https://www.openstreetmap.org/relation/8365033 (même le rendu a du mal
au passage…)


Ce n'est pas le rendu qui a un soucis, c'est le concepteur.

Car les inners ne sont pas disjoints. Donc tu as une partie qui est
décrite comme étant à la fois dedans et dehors : la partie commune est à
la fois limite intérieure au nord/extérieure au sud et limite extérieure
au nord/intérieure au sud.

Il faudrait créer une zone comportant toute la place qui n'est pas de
niveau et la mettre en inner de la relation.

Jean-Yvon

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

Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO

[Jérôme Seigneuret]

Ben en faite la zone ne tiens pas compte du bati ou non.
Les cave à fromage c'est tous le problème. l(IGP est à la fois sur la
provenance du lait et sur le lieu de production est de transformation.
C'est pour ça que l'on parle de territoire et pas forcément de parcellaire
Bref l'exploitation fait parti de l'IGP vu que le lieu de transformation
doit être sur place.

ok pour product et non produce



Le mer. 19 juin 2019 à 17:07, marc marc  a
écrit :

> à propos des étendues des appellations
>
> Le 19.06.19 à 14:41, Jérôme Seigneuret a écrit :
> > produce=* me semble largement suffisant
>
> cela signifierait que cette étendue fait tel produit
> hors ce n'est qu'une partie qui en fait.
> produce=* ne doit à mon avis pas déborder des terres
> ou des exploitations (pas de produce=* sur une étendue qui
> contient le magasin de chaussure et le bureau de poste)
>
> > boudary=produce_protection (ou produce_certification)
>
> oui pour quelques choses du genre
> voir product (le vin est un produit <> produce= c'est le raisin)
>
> > produce_protection:name=Indication Géographique Protégée
>
> sur la relation c'est encore + simple :
> name=
>
> > produce_protection:zone=UE, suisse, RPC
>
> ce serrait renseigner la législation, à éviter.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO

[Florimond Berthoux]

Bonjour,

Je saute dans la discussion pour dire rapidement :

1. les zones géographique de label devrait être faites en  zone
(polygone) et pas utiliser par des tags parce que la règle de One feature,
one OSM element
2. ce qui porte le label c'est le produit, le vin pas la vigne.
3. utiliser plutôt product parce que
«Produce or Product?
A guide by example. If the whole live animal/fish or plant is sold off the
'farm' then tag it as produce. If it is killed and then sold with little
processing then that is ok for tagging as produce. *If the processing is
'extensive' then it is a product=* not produce, so it should use the
product=* key.*»
La production de vin est un processus industriel complexe où le label peut
obliger à des limitations.
Clé à mettre plutôt sur le chai donc.

Le mer. 19 juin 2019 à 17:07, marc marc  a
écrit :

> à propos des étendues des appellations
>
> Le 19.06.19 à 14:41, Jérôme Seigneuret a écrit :
> > produce=* me semble largement suffisant
>
> cela signifierait que cette étendue fait tel produit
> hors ce n'est qu'une partie qui en fait.
> produce=* ne doit à mon avis pas déborder des terres
> ou des exploitations (pas de produce=* sur une étendue qui
> contient le magasin de chaussure et le bureau de poste)
>
> > boudary=produce_protection (ou produce_certification)
>
> oui pour quelques choses du genre
> voir product (le vin est un produit <> produce= c'est le raisin)
>
> > produce_protection:name=Indication Géographique Protégée
>
> sur la relation c'est encore + simple :
> name=
>
> > produce_protection:zone=UE, suisse, RPC
>
> ce serrait renseigner la législation, à éviter.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] routage surfacique

[lenny.libre]

Le 18/06/2019 à 20:33, marc marc a écrit :

j'ai bien vu cela (même si n'est pas compréhensible sur la capture)
mais aucun des 4 itinéraires n’atteint l'itinéraire réel
alors que ce sont 2 points de osm de la place.
donc même ce site a du limiter le nuage de way représentant la place.
alors imagine les dégâts si tu routes entre Paris et Monpellier
en surfacique.
A mon âge, je ne suis pas prêt de faire Paris Montpellier à pied (même 
quand j'étais jeune, je ne le faisais pas).

Le 18/06/2019 à 20:10, marc marc - marc_marc_...@hotmail.com a écrit :

Le 18.06.19 à 18:48, lenny.libre a écrit :

donc pour ma part, les routes donnant sur une place
se rejoignent en un point + souvent place=square
c'est une représentation imparfaite, mais c'est
à l'heure actuelle sans doute le meilleur compromis
Pour l'anomalie que j'avais signalée, comme le dit Phyks (2 accès sur la 
place à quoi bon tracer un chemin fictif qui n'est pas nécessaire aux 
calculateurs)
Pourquoi les outils évolueraient-ils, si on leur mâche le boulot ? 

les évolutions des tags dans osm se font généralement
- soit par des tags supplémentaires (highway puis maxspeed
puis lanes puis turn:lanes par ex)
- soit par un changement de tags (par ex power=sub_Station
divisé en 2 power=substation et power=generator).
Si on suit cette logique, c'est area:highway qui devrait
être utilisé pour une transitions sans dégradation.

casser en disant "yaka faire du routage surfacique",
c'est méconnaître ce que cela implique techniquement :
Tu caricatures ce que je dis, j'ai bien précisé "je sais, je ne devrais 
pas en parler ... , je serais bien incapable de faire ces outils" donc 
je ne suis peut-être pas technique, mais je remarque simplement qu'il y 
a des outils qui font sans ces "chemins"

il y a un gros travail de prétraitement à faire.
je ne retrouve plus hélas l'article qui était publiée sur osmweekly
mais la moindre place avec qlq rues est transformée en un nuage
de way qui connectent tous les paires de points de la surface.
en passant, cela veux dire aussi qu'une place surfacique
avec 8 nœuds consomme 9x l'espace disque et mémoire
comparé à sa version linéaire et ce n'est pas en un claquement
de doigt qu'on augmente la puissance d'un serveur gratuit.

je pense que les outils continueront de s'améliorer simplement
à la demande de leur utilisateur, en fonction des ressources dispo.


alors quehttps://moodwalkr.com/@montpellier/itineraire
peut calculer un itinéraire

https://framapic.org/nEjSW3hpuqm3/7c38wQyfPHD1.png
j'espère que tu partageras mon avis que l'amélioration par
rapport à une représentation filaire ne saute pas aux yeux
alors que le point de départ et d'arrivée sont accessible
en ligne droite sans obstacle.


Mais non, je ne partages pas ton avis, pas plus droit avec OSRM,


PS: je n'ai pas chercher à mettre l'outil en difficulté,
j'ai juste demandé la place et une adresse de la place.


Peut-être parce que la partie pour aller à une adresse précise sur une 
place est améliorable, (alors qu'il permet de faire des recherches 
d'itinéraire par thèmes.)


Tout produit est améliorable (tout comme mes contributions), je vais 
donc continuer à faire comme d'hab, je ne créerais pas de chemins 
virtuels et je n’effacerais pas ceux des copains.


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

Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO

[marc marc]

à propos des étendues des appellations

Le 19.06.19 à 14:41, Jérôme Seigneuret a écrit :
> produce=* me semble largement suffisant

cela signifierait que cette étendue fait tel produit
hors ce n'est qu'une partie qui en fait.
produce=* ne doit à mon avis pas déborder des terres
ou des exploitations (pas de produce=* sur une étendue qui
contient le magasin de chaussure et le bureau de poste)

> boudary=produce_protection (ou produce_certification)

oui pour quelques choses du genre
voir product (le vin est un produit <> produce= c'est le raisin)

> produce_protection:name=Indication Géographique Protégée

sur la relation c'est encore + simple :
name=

> produce_protection:zone=UE, suisse, RPC

ce serrait renseigner la législation, à éviter.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] routage surfacique

[Jérôme Seigneuret]

Pour l'exemple de Montpellier, les tracés ont été supprimés par mes soins
puis rajouté par les services de la métropole qui utilise des extractions
pour ses propres outils de routing (non OSM compliant) et qui existe
historiquement. Donc les linéaires correspondent à une nécessité de leurs
outils pour le routing et je pense pour l'intermodalité (adresse vers
adresse). (non compatible avec de l'itinéraire polygonale)

D'où un commentaire dans les tracés.
C'est pas la seul zone en double (voir la zone d'Odysseum) et il y a aussi
des tracés en double pour palier au problème d'affichage des noms (linéaire
plus zone en dessous)

L'autres système qui a encore d'autres implications c'est *area:highway=**.

Je suis d'accord que la double infos n'a pas d'intérêt et qu'il vaut mieux
faire un post traitement sous forme de maille avec détection d’obstacle
pour générer du tracé virtuel plutôt que ce que l'on voit sur ta capture
d'écran.




Le mer. 19 juin 2019 à 16:54, lenny.libre  a écrit :

>
> Le 18/06/2019 à 20:33, marc marc a écrit :
>
> j'ai bien vu cela (même si n'est pas compréhensible sur la capture)
> mais aucun des 4 itinéraires n’atteint l'itinéraire réel
> alors que ce sont 2 points de osm de la place.
> donc même ce site a du limiter le nuage de way représentant la place.
> alors imagine les dégâts si tu routes entre Paris et Monpellier
> en surfacique.
>
> A mon âge, je ne suis pas prêt de faire Paris Montpellier à pied (même
> quand j'étais jeune, je ne le faisais pas).
>
> Le 18/06/2019 à 20:10, marc marc - marc_marc_...@hotmail.com a écrit :
>
> Le 18.06.19 à 18:48, lenny.libre a écrit :
>
> donc pour ma part, les routes donnant sur une place
> se rejoignent en un point + souvent place=square
> c'est une représentation imparfaite, mais c'est
> à l'heure actuelle sans doute le meilleur compromis
>
> Pour l'anomalie que j'avais signalée, comme le dit Phyks (2 accès sur la
> place à quoi bon tracer un chemin fictif qui n'est pas nécessaire aux
> calculateurs)
>
> Pourquoi les outils évolueraient-ils, si on leur mâche le boulot ?
>
> les évolutions des tags dans osm se font généralement
> - soit par des tags supplémentaires (highway puis maxspeed
> puis lanes puis turn:lanes par ex)
> - soit par un changement de tags (par ex power=sub_Station
> divisé en 2 power=substation et power=generator).
> Si on suit cette logique, c'est area:highway qui devrait
> être utilisé pour une transitions sans dégradation.
>
> casser en disant "yaka faire du routage surfacique",
> c'est méconnaître ce que cela implique techniquement :
>
> Tu caricatures ce que je dis, j'ai bien précisé "je sais, je ne devrais
> pas en parler ... , je serais bien incapable de faire ces outils" donc je
> ne suis peut-être pas technique, mais je remarque simplement qu'il y a des
> outils qui font sans ces "chemins"
>
> il y a un gros travail de prétraitement à faire.
> je ne retrouve plus hélas l'article qui était publiée sur osmweekly
> mais la moindre place avec qlq rues est transformée en un nuage
> de way qui connectent tous les paires de points de la surface.
> en passant, cela veux dire aussi qu'une place surfacique
> avec 8 nœuds consomme 9x l'espace disque et mémoire
> comparé à sa version linéaire et ce n'est pas en un claquement
> de doigt qu'on augmente la puissance d'un serveur gratuit.
>
> je pense que les outils continueront de s'améliorer simplement
> à la demande de leur utilisateur, en fonction des ressources dispo.
>
>
> alors quehttps://moodwalkr.com/@montpellier/itineraire
> peut calculer un itinéraire
>
> https://framapic.org/nEjSW3hpuqm3/7c38wQyfPHD1.png
> j'espère que tu partageras mon avis que l'amélioration par
> rapport à une représentation filaire ne saute pas aux yeux
> alors que le point de départ et d'arrivée sont accessible
> en ligne droite sans obstacle.
>
> Mais non, je ne partages pas ton avis, pas plus droit avec OSRM,
>
> PS: je n'ai pas chercher à mettre l'outil en difficulté,
> j'ai juste demandé la place et une adresse de la place.
>
> Peut-être parce que la partie pour aller à une adresse précise sur une
> place est améliorable, (alors qu'il permet de faire des recherches
> d'itinéraire par thèmes.)
>
> Tout produit est améliorable (tout comme mes contributions), je vais donc
> continuer à faire comme d'hab, je ne créerais pas de chemins virtuels et je
> n’effacerais pas ceux des copains.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO

[marc marc]

Le 19.06.19 à 14:20, djo_man via Talk-fr a écrit :

> on est pas obligé de mapper des régions quand on a  
> des landuses déjà présents. Ils sont bien réels.

obligé bien sur que non, mais analogie avec les bâtiments :
on n'est pas obligé (c'est même "déprécié") de mettre quelques
millions de is_in:region= quand une poignée
de relation suffisent pour définir toutes les régions du pays.

cette poignée de relation permettrait par exemple de faire un export
depuis osm pour documenter la page wikipedia au lieu de passer en
revue 80k landuse=vineyard avec un risque d'erreur bien supérieur.

>> *=blabla AOP ou *=truc IGP ne va pas ?
> les landuses peuvent être à la fois AOP et IGP et leur nom est différent.

*="blabla AOP;truc IGP"

pour fusionner avec l'idée de Jérome, si tu veux le faire sur un landuse
crop=grape ou produce=grape (pléonasme implicite)
for:product="blabla AOP;truc IGP"
manque-t-il quelque chose ?

 > c'est pas de l'humour noir, c'est sarcastique...

ce n'était pas mon but d'être blessant.
mon but était de caricaturer l'inutile complication.

> les appellations françaises ne sont pas si simples donc...

donc simplifions en un truc compréhensible, utilisant
au maximum les tags existant lorsqu'ils conviennent afin
que les contributeurs retrouve des mécanismes connus.
sinon on aura juste un schéma de + qui se superpose aux autres
qui rend l'utilisation des données partielle et aléatoire.

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

Re: [Talk-GB] SuDS (Sustainable Urban Drainage Systems)

[Jez Nicholson]

My client GeoSmart are experts on SuDS, further reading at
https://geosmartinfo.co.uk/knowledge-hub/sustainable-drainage-systems/

Many/most planning applications for new developments now have to mitigate
the drainage area that has been lost to houses/drives/roads/etc. It can be
difficult to identify a SuDS installation as they are deliberately blended
into the site. It might just be a pond at the bottom of a larger dipped
area that'll take some of the bite out of a flash flood.



On Wed, Jun 19, 2019 at 2:46 PM SK53  wrote:

> Last night before visiting the pub we had a look at part of Sheffield's
> "Grey-to-Green" SuDS system. Unfortunately all my batteries ad packed up at
> this point, but there are some decent pictures on twitter
> .
> The bit we looked at was outside the courthouses. It consisted of :
>
>- A bio-swale. Planted with a colourful mixture of plants most of
>which I've forgotten now, although I do recall Jerusalem Sage. The ground
>was a gravel mix with presumably a geo-membrane underneath to retain water.
>A few birches were also planted along the length of the swale.
>Superficially this just looks from a distance like a large ornamental
>flower bed.
>- Concrete 'dams' periodically, along the swale, rising to within a
>few inches of pavement level and with a v-shaped notch in the centre.
>Obviously these are not really dams, more a type of weir, being designed to
>moderate the flow of water through pooling behind each dam. I've seen
>similar constructions in the Alps albeit on a larger scale.
>- At the bottom of the swale a more obvious drainage channel. Where
>the swale is broken for pedestrian access this runs in a recessed gutter
>covered by a grille.
>
> There are probably other features of the completed scheme which we didn't
> see. I notice many new-build housing estates will have an area set aside as
> a water retention basin.
>
> I've previously noted a SuDS along Ribblesdale Road
> 
> in Nottingham, but the features involved are on too small a scale to
> consider mapping for now.
>
> This type of infrastructure is becoming much more popular, particularly
> with extreme flooding events due to surface run-off. I'd hoped to look at
> the one in Sheffield, and fortunately Laura both remembered this and where
> it was. Larger ones are relatively simple to map the main features,
> choosing viable & appropriate tags is more challenging. I've had a go
> , but am very
> open to other suggestions. I suspect the whole swale should be mapped as a
> waterway feature. For now I've used waterway=drain with intermittent=yes
> for the channel in the swale & the connecting part of the drain running in
> a covered gutter (one import in Santa Clara Co, CA opted for
> waterway=stream). However many of the features could use man-made rather
> than waterway tags.
>
> In conclusion: there's probably a SuDS near you; they're hard to tag (for
> know); but not too hard to map; we could do with thinking about better tags.
>
> Regards,
>
> Jerry
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] SuDS (Sustainable Urban Drainage Systems)

[SK53]

Last night before visiting the pub we had a look at part of Sheffield's
"Grey-to-Green" SuDS system. Unfortunately all my batteries ad packed up at
this point, but there are some decent pictures on twitter
.
The bit we looked at was outside the courthouses. It consisted of :

   - A bio-swale. Planted with a colourful mixture of plants most of which
   I've forgotten now, although I do recall Jerusalem Sage. The ground was a
   gravel mix with presumably a geo-membrane underneath to retain water. A few
   birches were also planted along the length of the swale. Superficially this
   just looks from a distance like a large ornamental flower bed.
   - Concrete 'dams' periodically, along the swale, rising to within a few
   inches of pavement level and with a v-shaped notch in the centre. Obviously
   these are not really dams, more a type of weir, being designed to moderate
   the flow of water through pooling behind each dam. I've seen similar
   constructions in the Alps albeit on a larger scale.
   - At the bottom of the swale a more obvious drainage channel. Where the
   swale is broken for pedestrian access this runs in a recessed gutter
   covered by a grille.

There are probably other features of the completed scheme which we didn't
see. I notice many new-build housing estates will have an area set aside as
a water retention basin.

I've previously noted a SuDS along Ribblesdale Road

in Nottingham, but the features involved are on too small a scale to
consider mapping for now.

This type of infrastructure is becoming much more popular, particularly
with extreme flooding events due to surface run-off. I'd hoped to look at
the one in Sheffield, and fortunately Laura both remembered this and where
it was. Larger ones are relatively simple to map the main features,
choosing viable & appropriate tags is more challenging. I've had a go
, but am very open
to other suggestions. I suspect the whole swale should be mapped as a
waterway feature. For now I've used waterway=drain with intermittent=yes
for the channel in the swale & the connecting part of the drain running in
a covered gutter (one import in Santa Clara Co, CA opted for
waterway=stream). However many of the features could use man-made rather
than waterway tags.

In conclusion: there's probably a SuDS near you; they're hard to tag (for
know); but not too hard to map; we could do with thinking about better tags.

Regards,

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

Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO

[Jérôme Seigneuret]

Pour rentrer un peu plus dans le détail, voici les infos sur la base et
sont contenu parcellaire sous licence etalab2

 *Allias* (optionnel) Délimitations parcellaires AOP/IGP (INAO)

*Définition* La Directive 2015-03 de l’INAO désigne sous le terme « aire
parcellaire délimitée» une délimitation qui repose sur les limites
administratives du cadastre (les parcelles) et dont le maillage
suffisamment fin permet de tenir compte de variations très localisées des
éléments du milieu physique.
*La délimitation parcellaire des AOP/IGP est utilisée essentiellement pour
les vins*. Elle correspond dans ce cas à l’*aire de production de la
matière première*.
Elle est incluse dans une aire géographique qui constitue l’aire de
production du produit.
Elle est le résultat d’une procédure de délimitation validée par l’INAO.

*Regroupement* Parcelle, agrégat de parcelles ou de parties de parcelle

*Type d’objet *Polygone simple ou multiple

*Modélisation géométrique* La géométrie d'une aire parcellaire délimitée se
construit par l'*agrégation des polygones représentant les limites des
parcelles cadastrales vectorisées par commune mais agrégées à l’appellation*
dans cette base. Contraintes La généalogie des données induit des *hiatus
aux frontières des communes (des vides ou des superpositions)*. Leur
utilisation est optimale par la prise en compte d’un territoire communale
unique.
Les plans délimités officiels restent ceux détenus par l’INAO et déposés
dans les mairies des communes concernées par au moins une délimitation
parcellaire en AOP ou en IGP.

Donc en clair c'est basé sur les parcelles du cadastre.

Les limites concernant la date et le type de données
  L’utilisation du PCI-Vecteur par les services de l’INAO pour la
vectorisation des aires parcellaires date de 2008. A l’époque, le système
de référence utilisé était le Lambert II étendu. Il est ensuite passé au
Lambert 93

Maintenance
3 à 4 fois par an.

Avertissement
Ces données sont encore à l’état de constitution, elles ne sont pas
complètes et constituent à ce stade une version Bêta. L’INAO remercie toute
personne faisant remonter des anomalies pour permettre une amélioration de
la donnée.



Le mer. 19 juin 2019 à 14:41, Jérôme Seigneuret 
a écrit :

> si l'on par sur produce on est sur des éléments complémentaires de landuse
> qui sont en relation avec un produit donc plus cohérent
>
> Les IGP AOC se chevauchent vachement car il y en à pour plein de
> produits.  Il doit y avoir des limites communes... Peut être faudrait-il
> initier ce travail de recouvrement pour les relations avec une forme de
> topologie et pas une intégration de shape comme ça l'est des fois avec les
> Aire protégées...
>
> Le cahier des charges défini explicitement les territoires. Donc le shape
> peut aider mais ne doit pas servir pour faire les relations!!!
> De plus, c'est pas parce qu'on est dans une zone IGP AOC ou AOP que le
> terrain sert à produire une denrée en lien avec l'indication... donc rien à
> faire sur le landuse...
>
> Qui plus est, on est en lien avec un cahier des charges pour la production
> donc ce reporter au cahier des charges
>
> Marc ta proposition est pas mal ;-)  Mais on peut faire
> plus simple
>
> ref:FR:INAO
> ref;EU ?
>
> ou international? c'est pas reconnu qu'en France
>
> pour la clé produit
> produce=* me semble largement suffisant
> boudary=produce_protection (ou produce_certification)
> produce_protection:short_name=IGP
> produce_protection:name=Indication Géographique Protégée
> produce_protection:zone=UE, suisse, RPC
>
>  etc
> produce_protection:level= à définir car on n'est pas les seul à
> protéger nos productions et nos processus
>
> name=* plutôt qu'une denomination ou appelation est suffisant
> name:fr
> name:en
>
> Les labels sont IGP, AOC, AOP, et les autres label si tu veux jouer : Bio,
> label rouge, AB etc
>
> Attention les IGP peuvent être parcellaires!!!
>
> A+ Jérôme
>
>
>
>
>
> Le mer. 19 juin 2019 à 12:49, marc marc  a
> écrit :
>
>> Bonjour,
>>
>> Le 19.06.19 à 11:41, djo_man via Talk-fr a écrit :
>> > https://wiki.openstreetmap.org/wiki/Key:winery
>> > Cette page me semble inopérante
>>
>> elle est l’œuvre d'une seule personne connue pour faire des
>> pages controversées présentées comme "la bonne façon de faire"
>> on voit bien à la description et aux valeurs que cela ne rime
>> à rien et que cela réinvente une fois de plus ce qui existe
>> par ex le fait qu'un poi vend du vin est parfois renseigné par drink
>>
>> > car elle est basée sur le tag craft=winery
>> > plutot que landuse=vineyard.
>>
>> j'ai rien compris à l'argument : si le gars veux maper
>> le chai d'un bordeaux, je vois pas pq il devrait aller
>> maper la parcelle de la vigne qu'il n'a même pas visité.
>> ce sont 2 choses différente (c'est comme maper une
>> usine agroalimentaire de chips ou le champs de patate)
>>
>> > Je propose alors sur le landuse=vineyard (un ensemble de parcelles):
>> > - vineyard:regions= regions selon la page de wikipedia
>> > 

Re: [OSM-talk-fr] Re: zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO

[djo_man via Talk-fr]

  
  


  
https://wiki.openstreetmap.org/wiki/Key:winery
Cette page me semble inopérante

  


inopérante pour décrire le vin geographiquement car bien souvent, il y a plusieurs vins par domaine. ils peuvent etre de plusieurs AOP ou IGP et des fois rien pour certains domaines. par exemple, il est tres courant dans le beaujolais qu'il y ai 2 AOp différents plus un IGP. Cela vient du fait que les appellations sont assises sur les parcelles.

il pas question de taguer à la parcelle mais pour un landuse
donc il faut décrire ce qui est potentiellement possible sur le landuse

les appellations sont bien géographique

://en.wikipedia.org/wiki/List_of_wine-producing_regions
  si tu veux mapper des régions, mape des régions.


on est pas obligé de mapper des régions quand on a des landuses
  déjà présents. Ils sont bien réels.

je ne comprends pas la remarque de
  osm.sanspourr...@spamgourmet.com  : Loire Valley n'est pas une
  region adminstative. ces regions sont des dénominations qui sont
  aussi reprises sur le traité de lisbonne qui décrit les
  protections des AOP.

le nom des régions est important car par exemple : Madiran juste
  à coté de la région de Bordeaux à un nom très spécifique. 

Comme Champagne ou Bourgogne, Rhône. la limite être ses régions
  est importante


  
- vineyard:appellation:aop= issu de la base INAO ("appellation" car la 
WIPO (wolrd intellectual property organization) l'utilise 
  

oui, pourquoi pas mettre les termes internationaux. PDO et PGI

  je comprend pas la différence.
*=blabla AOP ou *=truc IGP ne va pas ?

les landuses peuvent être à la fois AOP et IGP et leur nom est
  différent. 

il faut trouver une manière de lister la classification puis leur
  nom
oui, peut être se limiter à ne mettre que
  vineyard:appellation:pdo = "name" et vineyard:appellation:pgi =
  "name"


  


c'est  pas de l'humour noir, c'est sarcastique...
les appellations françaises ne sont pas si simples donc...


djo


  ___
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] Musei

[Martin Koppenhoefer]

Gentile Lorenzo,

grazie per la risposta. Rispondo tra le righe e cito soltanto le parti alle
quale rispondo:

Am Di., 18. Juni 2019 um 09:03 Uhr schrieb Lorenzo Rolla <
rolla.l...@gmail.com>:

> Gentile Martin, provo a rispondere (è la prima volta che scrivo qui…).
>


intanto benvenuto!



> Preciso subito che mie fonti sono il MIBACT e i vari poli museali
> regionali. Il movente che mi ha spinto a intervenire intorno a numerosi
> musei è l’evidente esiguità delle informazioni disponibili a un potenziale
> visitatore. I miei interventi - generalmente limitati all’inserimento
> dell’orario, del sito web, della email e del numero di telefono - hanno
> solo lo scopo di accrescere il lavoro già eseguito da altri, certosino, ma
> oggettivamente insufficiente a orientare la scelta di visitare un luogo
> artistico o storico.
>


si, anche se poi con il sito web i lettori della mappa hanno un ottimo
riferimento per approfondire.



> Personalmente considero il mio irrisorio contributo una sorta di “civismo
> digitale” giovevole a suscitare un ideale contatto con il mondo delle arti,
> incontro in grado di elevare lo spirito e, perchè no, le menti dei miei
> concittadini. Il ragionato impulso di partecipare alla costruzione fattiva
> di questo spettacolare mondo delle mappe (incontro del tutto casuale e
> recente) è anche motivato dalla presa di coscienza di non ridurre la
> rappresentazione grafica dei luoghi a un mero esercizio di toponomastica,
> ma di creare le opportunità (da cogliere o meno) di una maggiore
> consapevolezza della realtà circostante.
>


concordo in pieno. Anch'io ho spesso mappato e arricchito musei e le
considero punti importanti da mappare, sia in posizione e nome, che anche
con i loro dati "di corredo". Mi piacerebbe aggiungere a tutti i musei
anche un tag che descrive in maniera grezza (all'inizio) di cosa si tratta,
attualmente i tag in uso sono questi:
https://taginfo.openstreetmap.org/keys/museum#values
https://taginfo.openstreetmap.org/keys/museum_type#values

putroppo nel è del tutto chiaro cosa decrivono i tag, ma ha prima vista il
tag "museum_type" è utilizzato più per mappare il tipo di operatore
(municipal, private, national, departmental ("departement" francesi),
republican (immagino sia un doppione di "national"), "public"

Mentre il tag "museum" è più usato per il tema: history, railway, art,
local, maritime, science...

Ci sono ancora un po' di problemi (per esempio "open air" non dice di cosa
si tratta, anche se poi ho un idea cosa è inteso ("Freiluftmuseum"), ma
direi che un filo rosso si vede.




> Ecco in sintesi la ragione della mia industriosa presenza in questo luogo.
> Ad maiora. Lorenzo.
>


prendendo dati individualmente dal sito ufficiale del posto non è un
problema, ovviamente ben venga, dalla prima mail sembra un import non
annunciato.

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

Re: [OSM-talk] Proposed mechanical edit - addition of office=diplomatic to amenity=embassy with country=*

[Joseph Eisenberg]

I've spent several hours creating wiki pages for the new, approved
tags from this proposal, so I'm in favor of the tags, even
office=diplomatic (which doesn't seem much of an improvement, compared
to the others).

But I'm not convinced that adding the office=diplomatic tag to
existing features is very helpful. It would be more useful to add
diplomatic=embassy/consulate/liaison and the additional subtags to
show the precise type of embassy or consulate or other diplomatic
facility, but this probably requires local survey or at least
extensive searching of web pages for every feature.

On 6/19/19, Frederik Ramm  wrote:
> Hi,
>
> On 18.06.19 03:21, Warin wrote:
>> Following the successful proposal of introducing office=diplomatic to
>> eventually replace the amenity=embassy (which is used to not only tag
>> embassies but other diplomatic service) I am proposing to add the
>> approved tag office=diplomatic to all instances that have both the tag
>> amenity=embassy with the tag country=*.
>
> I don't think that this is necessary or helpful. When office=diplomatic
> was "approved", we did not discuss a mass addition to existing features.
> This is something that time can solve, we don't need an automatic edit
> for it.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO

[Jérôme Seigneuret]

si l'on par sur produce on est sur des éléments complémentaires de landuse
qui sont en relation avec un produit donc plus cohérent

Les IGP AOC se chevauchent vachement car il y en à pour plein de produits.
Il doit y avoir des limites communes... Peut être faudrait-il initier ce
travail de recouvrement pour les relations avec une forme de topologie et
pas une intégration de shape comme ça l'est des fois avec les Aire
protégées...

Le cahier des charges défini explicitement les territoires. Donc le shape
peut aider mais ne doit pas servir pour faire les relations!!!
De plus, c'est pas parce qu'on est dans une zone IGP AOC ou AOP que le
terrain sert à produire une denrée en lien avec l'indication... donc rien à
faire sur le landuse...

Qui plus est, on est en lien avec un cahier des charges pour la production
donc ce reporter au cahier des charges

Marc ta proposition est pas mal ;-)  Mais on peut faire
plus simple

ref:FR:INAO
ref;EU ?

ou international? c'est pas reconnu qu'en France

pour la clé produit
produce=* me semble largement suffisant
boudary=produce_protection (ou produce_certification)
produce_protection:short_name=IGP
produce_protection:name=Indication Géographique Protégée
produce_protection:zone=UE, suisse, RPC

 etc
produce_protection:level= à définir car on n'est pas les seul à
protéger nos productions et nos processus

name=* plutôt qu'une denomination ou appelation est suffisant
name:fr
name:en

Les labels sont IGP, AOC, AOP, et les autres label si tu veux jouer : Bio,
label rouge, AB etc

Attention les IGP peuvent être parcellaires!!!

A+ Jérôme





Le mer. 19 juin 2019 à 12:49, marc marc  a
écrit :

> Bonjour,
>
> Le 19.06.19 à 11:41, djo_man via Talk-fr a écrit :
> > https://wiki.openstreetmap.org/wiki/Key:winery
> > Cette page me semble inopérante
>
> elle est l’œuvre d'une seule personne connue pour faire des
> pages controversées présentées comme "la bonne façon de faire"
> on voit bien à la description et aux valeurs que cela ne rime
> à rien et que cela réinvente une fois de plus ce qui existe
> par ex le fait qu'un poi vend du vin est parfois renseigné par drink
>
> > car elle est basée sur le tag craft=winery
> > plutot que landuse=vineyard.
>
> j'ai rien compris à l'argument : si le gars veux maper
> le chai d'un bordeaux, je vois pas pq il devrait aller
> maper la parcelle de la vigne qu'il n'a même pas visité.
> ce sont 2 choses différente (c'est comme maper une
> usine agroalimentaire de chips ou le champs de patate)
>
> > Je propose alors sur le landuse=vineyard (un ensemble de parcelles):
> > - vineyard:regions= regions selon la page de wikipedia
> > https://en.wikipedia.org/wiki/List_of_wine-producing_regions
>
> si tu veux mapper des régions, mape des régions.
> ex 12 relations type=boundary boundary=wine ou truc du genre.
> dire que chaque parcelle de Bordeaux peux produire un vin de Bordeaux,
> c'est lourd
>
> > - vineyard:classification= AOP ou/et IGP
>
> il y a un cas d'usage ou quelqu'un connaîtrait le fait que c'est une aop
> mais ne serrait pas capable de renseigner le nom de l'aop dans l'un des
> tags que tu proposes ensuite ? sinon c'est juste doublon
> ce serrait comme mettre name:classification=Rue name=Rue de la gare
>
> > - vineyard:appellation:aop= issu de la base INAO ("appellation" car la
> > WIPO (wolrd intellectual property organization) l'utilise
> > https://www.wipo.int/ipdl/en/search/lisbon/search-struct.jsp)
> > - vineyard:appellation:igp= issu de la base INAO (conforme à l'europe)
> > - vineyard:denomination= issu de la base INAO ("denomination" franco
> > français mais pas uniquement car d'autre régions du monde ont repis
> l'idée)
>
> je comprend pas la différence.
> *=blabla AOP ou *=truc IGP ne va pas ?
>
> > ça fait réagir quelqu'un ?
>
> 
> je pense qu'il faut faire beaucoup plus compliqué
> et différent de tout ce qui existe déjà
> sinon cela risque d'être utilisable et pire utilisé
> il faut aussi ne pas hésiter à rallonger avec plein de namespace
> pour que chaque tag ne soie utilisable que sur un objet
> genre vineyard:appellation:aop qui n'est possible qu'en France
> (puisqu'en anglais c'est pdo), que sur un vignoble, etc
> je propose ref:FR:vineyard:appellation:aop:INAO:2019=*
> mais on doit pouvoir sûrement faire + long.
> 
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] routage surfacique

[Phyks]

Bonjour,


casser en disant "yaka faire du routage surfacique",
c'est méconnaître ce que cela implique techniquement :
il y a un gros travail de prétraitement à faire.
je ne retrouve plus hélas l'article qui était publiée sur osmweekly
mais la moindre place avec qlq rues est transformée en un nuage
de way qui connectent tous les paires de points de la surface.
en passant, cela veux dire aussi qu'une place surfacique
avec 8 nœuds consomme 9x l'espace disque et mémoire
comparé à sa version linéaire et ce n'est pas en un claquement
de doigt qu'on augmente la puissance d'un serveur gratuit.

je pense que les outils continueront de s'améliorer simplement
à la demande de leur utilisateur, en fonction des ressources dispo.


Dans la plupart des cas, le routage surfacique n'est pas un problème 
quand même. Je mets volontairement de côté une place aussi complexe que 
https://www.openstreetmap.org/relation/8365033 (même le rendu a du mal 
au passage…) pour se concentrer sur des espaces sans trous (tels que les 
espaces dans l'erreur Osmose initiale 
https://osmose.openstreetmap.fr/fr/map/#item=1270=18=47.497894=-0.580999=1%2C2%2C3==).



La plupart des moteurs de routage ne vont pas gérer le routage 
surfacique à travers la place (qui est un problème compliqué). En 
revanche, tous vont pouvoir traiter la place comme un way fermé (le 
contour) et tous savent a priori emprunter des portions de way. Du coup, 
le routage ne sera pas "joli" (on ne va pas traverser la place comme on 
le voudrait, simplement contourner en suivant la bordure), mais le 
routage restera néanmoins fonctionnel.


Dans un cas simple comme ceci, à mon avis, il n'y a aucune raison de 
tracer des continuités des chemins à travers les places, si ce n'est 
alourdir la base avec des ways inutiles (et qui n'existent pas sur le 
terrain). La description en termes d'air a une réelle plus value 
(notamment pour le rendu, mais pas que), et reste parfaitement 
utilisable, à condition que les aires portent bien les attributs 
corrects (highway et droits d'accès).


Sur un cas similaire à l'exemple initial d'Osmose :
* BRouter suit le contour, 
http://brouter.de/brouter-web/#map=19/45.77393/3.08337/standard=3.083773,45.77412;3.083596,45.773869
* Géovélo aussi, 
https://www.geovelo.fr/clermont/itinerary/search?profile=MEDIAN=TRADITIONAL=45.774108,3.08372%7C45.7739,3.0836
* GraphHopper et OSRM aussi, 
https://www.openstreetmap.org/directions?engine=graphhopper_foot=45.77411%2C3.08376%3B45.77387%2C3.08360



Mon avis serait donc que sur des places simples (sans trou), il suffit 
de connecter le polygone aux chemins voisins et tout tracé de chemin en 
travers du polygone relève plutôt du "tag to router", en créant des 
chemins qui amélioreront le rendu du routage, mais en aucun cas sa 
justesse.


D'ailleurs, malgré l'erreur Osmose, le routage se fait très bien 
http://brouter.de/brouter-web/#map=19/47.49783/-0.58158/standard=-0.581248,47.497738;-0.581433,47.498012.



Ma remarque ne tient plus évidemment lorsqu'on considère des surfaces 
avec des trous (multipolygone) où le routage est épouvantable et 
catastrophique s'il n'y a pas de chemins intérieurs "fictifs", comme le 
montre 
http://brouter.de/brouter-web/#map=17/48.84022/2.32019/standard=2.319813,48.841791;2.321146,48.841137=hiking-beta 
par exemple (BRouter ne gère pas le routage surfacique). Ce point est 
beaucoup plus sujet à débat à mon avis et des chemins "fictifs" 
pourraient être justifiés, même si certains ont des avis assez tranchés 
sur la question https://www.openstreetmap.org/note/1654211.

--
Phyks

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

Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO

[marc marc]

Bonjour,

Le 19.06.19 à 11:41, djo_man via Talk-fr a écrit :
> https://wiki.openstreetmap.org/wiki/Key:winery
> Cette page me semble inopérante

elle est l’œuvre d'une seule personne connue pour faire des
pages controversées présentées comme "la bonne façon de faire"
on voit bien à la description et aux valeurs que cela ne rime
à rien et que cela réinvente une fois de plus ce qui existe
par ex le fait qu'un poi vend du vin est parfois renseigné par drink

> car elle est basée sur le tag craft=winery
> plutot que landuse=vineyard.

j'ai rien compris à l'argument : si le gars veux maper
le chai d'un bordeaux, je vois pas pq il devrait aller
maper la parcelle de la vigne qu'il n'a même pas visité.
ce sont 2 choses différente (c'est comme maper une
usine agroalimentaire de chips ou le champs de patate)

> Je propose alors sur le landuse=vineyard (un ensemble de parcelles):
> - vineyard:regions= regions selon la page de wikipedia 
> https://en.wikipedia.org/wiki/List_of_wine-producing_regions

si tu veux mapper des régions, mape des régions.
ex 12 relations type=boundary boundary=wine ou truc du genre.
dire que chaque parcelle de Bordeaux peux produire un vin de Bordeaux, 
c'est lourd

> - vineyard:classification= AOP ou/et IGP

il y a un cas d'usage ou quelqu'un connaîtrait le fait que c'est une aop
mais ne serrait pas capable de renseigner le nom de l'aop dans l'un des
tags que tu proposes ensuite ? sinon c'est juste doublon
ce serrait comme mettre name:classification=Rue name=Rue de la gare

> - vineyard:appellation:aop= issu de la base INAO ("appellation" car la 
> WIPO (wolrd intellectual property organization) l'utilise 
> https://www.wipo.int/ipdl/en/search/lisbon/search-struct.jsp)
> - vineyard:appellation:igp= issu de la base INAO (conforme à l'europe)
> - vineyard:denomination= issu de la base INAO ("denomination" franco 
> français mais pas uniquement car d'autre régions du monde ont repis l'idée)

je comprend pas la différence.
*=blabla AOP ou *=truc IGP ne va pas ?

> ça fait réagir quelqu'un ?


je pense qu'il faut faire beaucoup plus compliqué
et différent de tout ce qui existe déjà
sinon cela risque d'être utilisable et pire utilisé
il faut aussi ne pas hésiter à rallonger avec plein de namespace
pour que chaque tag ne soie utilisable que sur un objet
genre vineyard:appellation:aop qui n'est possible qu'en France 
(puisqu'en anglais c'est pdo), que sur un vignoble, etc
je propose ref:FR:vineyard:appellation:aop:INAO:2019=*
mais on doit pouvoir sûrement faire + long.


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

Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO

[osm . sanspourriel]

Ça me fait réagir : la page liste les régions administratives, pas les
AOP/IGP.

Le 19/06/2019 à 11:41, djo_man via Talk-fr - talk-fr@openstreetmap.org a
écrit :

- vineyard:regions= regions selon la page de wikipedia
https://en.wikipedia.org/wiki/List_of_wine-producing_regions


De plus l'abréviation d'IGP est PGI en anglais (protected geographical
indication).

Et celle d'AOP est PDO (protected designation of origin).

Source : IATE évidemment

https://iate.europa.eu/search/standard/result/1560939408913/1

https://iate.europa.eu/search/standard/result/1560939330717/1

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

Re: [OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO

[djo_man via Talk-fr]

  
  

Une page du wiki m'en a donné l'idée.
  https://wiki.openstreetmap.org/wiki/Key:winery

Cette page me semble inopérante car elle est basée sur le tag
  craft=winery + winery= "" plutot que landuse=vineyard. 

En europe et assez largement dans le monde ou des appellations
  sont présentes, le classement des vins est basé sur le type de
  cépages sur des parcelles repérées donc de la vigne.


Je propose alors sur le landuse=vineyard (un ensemble de
  parcelles):
- vineyard:regions= regions selon la page de wikipedia
  https://en.wikipedia.org/wiki/List_of_wine-producing_regions
- vineyard:classification= AOP ou/et IGP
- vineyard:appellation:aop= issu de la base INAO ("appellation"
  car la WIPO (wolrd intellectual property organization) l'utilise
  https://www.wipo.int/ipdl/en/search/lisbon/search-struct.jsp)
- vineyard:appellation:igp= issu de la base INAO (conforme à
  l'europe)

- vineyard:denomination= issu de la base INAO ("denomination"
  franco français mais pas uniquement car d'autre régions du monde
  ont repis l'idée)
on pourrait rajouter le reste au besoin :
- vineyard:grape= cépages selon la page wikipedia
  https://en.wikipedia.org/wiki/List_of_grape_varieties (il faudrait
  le faire à la parcelle mais on le fait bien pour les arbres...)


ça plait ?

ça fait réagir quelqu'un ?
djoman



Le 17/06/2019 à 10:07, djo_man via
  Talk-fr a écrit :


  
  
  Bonjour à tous, 
  
  Je ne trouve pas de file de discussion parlant de la
possibilité de préciser par un tag les appellations AOC/AOP/IGP
des zones landuse=vineyard.
  On en a jamais parlé ? si ?
  
  https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dvineyard
  
  l'INAO en France fourni actuellement un shp des zones
d'appellation (480Mo !) et met actuellement à jour sa base. Une
reforme est en ce moment en cours pour simplifier et rénover les
périmètres. Une bonne moitié des périmètres sont déjà approuvés
et disponibles sur le site de l'INAO. Le reste est en cours de
concertation et les projets sont disponibles sur le site de
l'INAO.
  https://www.inao.gouv.fr/Espace-professionnel-et-outils/Suivi-des-demarches/Consultations-publiques-des-projets-d-aires-geographiques-ou-parcellaires-delimitees-des-AOC-et-IGP
  
  Personnellement, je n'envisage pas d'intégrer les périmètres
mais plutôt d'ajouter 1 tag ou 2 sur des ways existants de
landuse=vineyard en les recoupant au besoin.
  
  Djoman
  
  
  
  ___
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] exporter les tags d'un projet/style vers taginfo

[Phyks via Talk-fr]

Bonjour à tous,

Pour donner un peu plus de détails sur la question, j'ai actuellement un 
script 
(https://github.com/cyclosm/cyclosm-cartocss-style/blob/master/scripts/generate_taginfo.py) 
qui permet à partir d'un fichier YAML de déclaration de style CartoCSS 
(testé sur CyclOSM, mais ça devrait fonctionner tout pareil sur osm-fr, 
osm-bzh etc) de générer un fichier JSON pour taginfo listant tous les 
tags utilisés. Le seul pré-requis pour l'instant est que la base de 
données utilisée soit une base de données standard d'un import osm2pgsql 
(pour les noms des colonnes), éventuellement avec --hstore.


Mon problème principal actuellement, c'est que j'aimerais pouvoir avoir 
dynamiquement la liste des valeurs (et non seulement les tags) utilisés. 
Par exemple (hypothétique), je voudrais savoir que j'affiche les 
shop=bicycle mais pas tous les autres shop. Le problème est que le 
filtrage peut se faire dans les tables SQL ou dans les styles carto, 
sans compter que les colonnes peuvent être fusionnées, renommées etc 
dans les requêtes SQL. Bref, ça me paraît très compliqué de sortir les 
valeurs vraiment prises en compte sans se constraindre assez fortement 
sur les requêtes SQL qu'on peut écrire.


En y réfléchissant un peu, une idée me semble être de faire tourner les 
requêtes SQL complètes sur une grosse base (monde ?) et de regarder les 
valeurs uniques pour chaque colonne. Ce ne sera pas parfait (une valeur 
pourrait être ignorée car elle n'est pas en base et non parce qu'elle 
n'est pas gérée par le style), mais ça devrait fournir une assez bonne 
approximation en général.


Ceci n'est bien sûr pas parfait, j'ignore notamment les colonnes dans 
les clauses WHERE ainsi que des valeurs renommées / fusionnées / 
transformées dans les requêtes SQL, mais ça devrait être "good enough" 
pour la plupart des usages. Qu'en pensez-vous ?


Je prends bien sûr tout avis ou idée pour gérer ça mieux !

Bonne soirée,
--
Phyks

Le 2019-06-06 18:10, marc marc a écrit :

Bonjour,

Je discutais avec Phyks sur irc à propos de la fonction projet
de taginfo. elle permet de connaitre la liste des tags et/ou
valeurs utilisé par un projet.
C'est pratique par exemple pour faire la différence entre
des tags utilisé ou pas encore, ou pour savoir qui prévenir
quand un tag est affecté par une proposition.
A mes yeux, ce serrait aussi pratique pour détecter
quand un poi est rendu dans un style mais pas dans un autre,
afin de pouvoir faire des PR croisé du code ou de l’icône.

exemple de tag déclaré par des projets
https://taginfo.openstreetmap.org/projects#tags

exemple tag utilisant des vues
https://github.com/giggls/openstreetmap-carto-de/issues/39

une adaptation tag avec les tables sans vue
https://github.com/cyclosm/cyclosm-cartocss-style/issues/123

exemple tag
https://github.com/der-stefan/OpenTopoMap/blob/master/mapnik/tools/maketaginfo.pl

les problèmes :
le premier utilise des vues ce qui n'est pas le cas par défaut
sur un fork osm-carto
le deuxième ne gère pas les valeurs, seulement les tags
et selon Phyks le troisième a le défaut "meh, du perl :("

j'ouvre donc ce sujet pour voir si les différentes personnes
(Christian, Maël, Yohan, sncf?, autre ?) serraient intéressées de :
- mettre en place la création du fichier nécessaire pour taginfo
avec leur projet (je peux ouvrir les tickets si vous voulez)
- collaborer pour améliorer les outils existant

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


--
Phyks

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

Re: [OSM-talk] Proposed mechanical edit - addition of office=diplomatic to amenity=embassy with country=*

[Frederik Ramm]

Hi,

On 18.06.19 03:21, Warin wrote:
> Following the successful proposal of introducing office=diplomatic to
> eventually replace the amenity=embassy (which is used to not only tag
> embassies but other diplomatic service) I am proposing to add the
> approved tag office=diplomatic to all instances that have both the tag
> amenity=embassy with the tag country=*.

I don't think that this is necessary or helpful. When office=diplomatic
was "approved", we did not discuss a mass addition to existing features.
This is something that time can solve, we don't need an automatic edit
for it.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

[OSM-talk-fr] Nomad Maps, le film, est en ligne!

[alban vivert]

Bonjour à tous,

J'ai le plaisir de vous partager le lien de mon film "Nomad Maps, une
itinérance cartographique andine à vélo", sur le Peertube d'OSM France.
A ce jour j'ai les sous titres en français et espagnol, les sous titres
anglais arriveront dans les prochains jours.

https://peertube.openstreetmap.fr/videos/watch/384d14d7-9d19-4d15-a958-74aae719b48f

Le film est en CC BY SA 3.0, vous pouvez bien entendu l'utiliser comme
matériel pédagogique et faire tourner dans vos réseaux.
Si vous souhaitez organiser une projection dans une asso ou autre vers chez
vous en ma présence pour un "ciné débat", n'hésitez pas à me contacter.

Au plaisir et bonne visualisation!

à bientôt,


*  Alban Vivert*
http://www.nomadmaps.net/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Il DB di Geofabrik

[Luca Delucchi]

On Wed, 19 Jun 2019 at 07:30, aldoct  wrote:
>
> Non penso sia questa la spiegazione. I dati presenti nel DB di OSM sono
> sempre gli stessi. Il "cosa" vedere e "come" vedere questi dati dipende
> invece non dal software (Basecamp o altri); bensì dalle istruzioni che
> abbiamo dato nella compilazione della mappa. Chi usa installare le mappe
> tramite il file mtbmap.exe ha visto che in fase di setup puoi scegliere un
> layout differente. Quindi lo stesso dato può essere mostrano oppure no e può
> essere visto in un modo piuttosto che in un altro (una strada può essere
> rossa o verde). Nel caso delle autostrade si tratta di dati aggiuntivi (le
> vecchie tracce), non della loro visualizzazione. Da come ho capito io, da un
> unico DB, alcuni "soggetti" (Geofabrik è uno di questi ed è il più seguito)
> lo elaborano, mettendolo a disposizione per il download. Farò un controllo
> scaricando gli stessi dati da un'altra fonte
> (http://garmin.openstreetmap.nl/).
>

ho scaricato il file incriminato da geofabrik e visualizzato in QGIS e
non c'è nessun problema.
Perciò penso che il problema sia in basecamp

-- 
ciao
Luca

www.lucadelu.org

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

Re: [OSM-talk] Proposed mechanical edit - addition of office=diplomatic to amenity=embassy with country=*

[Mateusz Konieczny]

18 Jun 2019, 03:21 by 61sundow...@gmail.com:

> Any thoughts?
>
Remember to follow 
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct 

(for example - documenting mechanical edit on wiki)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-fr] OpenEventDatabase - était OpenStreetMap dans « Libre à vous ! » - demain mardi 11 juin sur radio Cause Commune

[Yves P.]

>
> Bonjour,
Christian, Avais tu essayé d'importer les données TMC ?

https://fr.m.wikipedia.org/wiki/Traffic_Message_Channel
--
Yves


> « Christian Quest : Oui. Tout à fait. OpenStreetMap a vocation à décrire
> le monde, on va dire un monde un petit peu statique, une base de données
> géographiques mais relativement statiques avec des choses qui ont de la
> pérennité. Donc tout ce qui est très temporaire comme des travaux, des
> bouchons ou des accidents, effectivement ça n’a pas sa place dans la
> base OpenStreetMap.
> Je vais faire une toute petite parenthèse : j’ai essayé de démarrer un
> projet qui s’appelle OpenEventDatabase pour venir combler ce manque et
> pour venir compléter OpenStreetMap en apportant des données qui, elles,
> sont localisées dans l’espace mais aussi dans le temps, donc avec des
> choses beaucoup plus liées au temps réel. Mais là, pareil, il va falloir
> qu’il y ait de la collaboration, il faut que tout le monde partage ses
> données en temps réel, ce qui n’est pas évident. Déjà, quand on a
> démarré, ce n’était pas évident pour les données cartographiques, mais
> alors pour les données en temps réel. aujourd’hui c’est encore considéré
> comme le petit trésor ! »1
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-se] Något har pajat utanför Katrineholm (var det jag?)

[Ture Pålsson via Talk-se]

2019-06-18 22:48 skrev Christian Asker:

> Hej. Ja nu ser det ok ut för mig med. Jag ändrade multipolygoner för vatten 
> och sen försvann land, så jag blev lite nervös.

Jag såg här att det tydligen varit något globalt problem med
kustlinjerna:
https://www.reddit.com/r/openstreetmap/comments/c1a0ha/help_someone_has_not_closed_the_rivers_properly/___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [talk-au] GHG mitigation and FOSS4G SotM Oceania

[Tony via Talk-au]

The upshot of the conversation is that we?re looking at ways to mitigate
our impact on the planet using something other than throwing money at
offsetters


Hi

I made contact with Parks Victoria (Australia). They are not in the  
business of providing carbon offsets but they would consider accepting  
money in return for agreeing to revegetate an area of land, resulting  
in carbon sequestration. The revegetation species mix would be  
carefully chosen to restore biodiverse bushland.


Contact me if you want to follow this idea up.

Tony



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

Re: [Talk-GB] Snowdonia National Park missing?

[Peter Neale via Talk-GB]

Dave,
Sorry to jump in, but perhaps your response was a little harsh?
Even given such advice, not all mappers will feel confident to fix an issue. 
Perhaps it is better that they ask for help (again), rather than ignore the 
issue, or try to fix it an just make matters worse?
Peter

Sent from Yahoo Mail on Android 
 
  On Tue, 18 Jun 2019 at 21:31, Dave F via Talk-GB 
wrote:   ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
  
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb