Re: [Talk-it] Landuse (aridaje)

[Lorenzo Mastrogiacomi]

Il giorno ven, 12/05/2017 alle 00.53 -0700, Max1234Ita ha scritto:
> 
Oggi, però, tornando su un'area da me mappata qualche tempo fa (poco
> distante da quella indicata sopra, tra l'altro), mi sono imbattuto in un
> certo numero di oggetti come questo: 
> https://www.openstreetmap.org/way/258756153/history#map=16/44.9768/9.0981=N
> 
>  
> , che erano separati, seppur vicini, ma sono stati  "riappiccicati" agli
> altri in uno o più changeset dal titolo "unito landuse leggermente
> distaccati".

In questo caso per me è giusto tenere i landuse=vineyard uniti, in
fondo è un unico vigneto e le strade ne fanno parte. Già il fatto di
averlo mappato con più aree a seconda dell'orientamento delle vigne è
una mappatura di precisione. Non che mi dispiaccia :)

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

Re: [OSM-talk] new Wikidata+OSM data in one RDF database

[Eugene Alvin Villar]

So what is the license of this combined database and is this combined
database a whole database or a collective database? Note that Wikidata is
under CC0 while OSM is under ODbL.

On Sat, May 13, 2017 at 12:03 AM, Yuri Astrakhan 
wrote:

> TLDR: A SPARQL (rdf) database with both OSM and Wikidata data is up for
> testing.  Allows massive cross-referenced queries between two datasets. The
> service is a test, and needs a permanent home to stay alive.
>
> Overpass Turbo is awesome, but sadly it does not have data from Wikidata,
> nor does it support some SQL-like conditions. I have setup a temporary RDF
> database that has both OSM & Wikidata. You can use SPARQL queries to find:
>
> * All OSM objects with wikidata tag that references a Wikipedia
> disambiguation page. Get the name of the page in first available language
> ru, fr, de, en.http://tinyurl.com/mzlfb26
>
> * OSM relations with wikidata tag pointing to a person (also tries
> multiple language fallbacks).  http://tinyurl.com/m6fh3wx
>
> * OSM relations with duplicate Wikidata IDs http://tinyurl.com/mvhhogx
>
>
> == OSM data structure ==
> osmnode, osmway, osmrel - OSM object prefix, e.g.  osmnode:1234
> osmt - tag, e.g.  osmt:name:en  (only has tags with latin chars, -, _, :,
> digits
> osmm - meta data about the object -- type, isClosed, version.
>
> I try to preserve OSM data without much changes. Every tag's value is
> stored as a string, except for wikidata and wikipedia tags which are
> converted to a URL, the same format as stored in Wikidata.
>
> osmway:29453885
>   osmt:name "Samina";
>   osmt:waterway "river";
>   osmt:wikidata wd:Q156065;
>   osmt:wikipedia ;
>   osmm:type "w";    could be "r", "w", and "n"
>   osmm:isClosed false;     this meta property is only for OSM ways
>   osmm:version 24.
>
> Wikidata data structure is identical to https://query.wikidata.org (see
> help)
>
>
> == Current limitations ==
> * Only includes OSM objects with either "wikidata" or "wikipedia" tags
> * The OSM data only contains tags with only Latin letters, digits and
> symbols - : _
> * OSM geometry info is not imported, e.g. no center point or bounding box,
> except for osmm:isClosed (true/false) property for ways.
> * Does not include OSM object inheritance data - e.g. cannot query for
> "find a node that is part of a way which is part of a relation that has
> wikidata tag that ..."
> * Wikidata is updated every second, but OSM does not yet update at all,
> imported from a full db dump as of a few days ago.
>
> ___
> 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] Revisiting traffic control and traffic calming

[Marc Gemis]

ok, multiple from in a relation will solve this.
Isn't it a problem that some "from"s do not end in some "intersection"s ?

On Fri, May 12, 2017 at 8:31 AM, Paul Johnson  wrote:
>
>
> On Fri, May 12, 2017 at 1:28 AM, Marc Gemis  wrote:
>>
>> On Fri, May 12, 2017 at 8:20 AM, Paul Johnson  wrote:
>> >
>> >> to: the collection of ways one can travel to after stopping/giving
>> >> way/waiting for traffic signal. This would include the from way so
>> >> u-turns have to obey the sign/signal as well.
>> >
>> >
>> > Yes.  At a minimum, a stop, give_way, traffic_signals or traffic_calming
>> > relation would have 1 from, 1 intersection and 1 to.
>>
>> Does that mean that for the examples on
>> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals with
>> at least 1 dual carriage way, one will need 4 relations ?
>
>
> Simplest case, traffic signal impacts all movements, dual carriageway
> north-south, single-carriageway east-west, you would have 1 relation with
> four from, four to, and two intersection roles.
>

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

Re: [Talk-it] Landuse (aridaje)

[Alessandro]

Il 12/05/2017 09:53, Max1234Ita ha scritto:

Ciao a tutti,
mi sorge un dubbio circa la mappatura dei landuse: di solito, tendo a
mapparli in modo da tenerli separati tra loro, ad esempio così:
https://www.openstreetmap.org/#map=16/44.9821/9.1204=N


Oggi, però, tornando su un'area da me mappata qualche tempo fa (poco
distante da quella indicata sopra, tra l'altro), mi sono imbattuto in un
certo numero di oggetti come questo:
https://www.openstreetmap.org/way/258756153/history#map=16/44.9768/9.0981=N




Ciao,
premesso che quell'aridaje lo vedremo spesso a meno che non si raggiunga 
un accordo su come mapparli con relativa pagina wiki.


Nell'esempio che hai indicato, d'accordo con quello che scrive Martin, 
non vedo grosse controindicazioni. Per fare le cose precise io avrei 
lasciato fuori dal landuse le track.


Altra cosa è quando si attaccano strade, fiumi, edifici: quando mi 
imbatto in quelle situazioni sento una fitta al fegato.


Alessandro Ale_Zena_IT

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

Re: [Talk-it] Landuse (aridaje)

[Lorenzo "Beba" Beltrami]

Il giorno 12 maggio 2017 10:39, Simone Saviolo 
ha scritto:

> Il giorno 12 maggio 2017 09:53, Max1234Ita  ha
> scritto:
>
>> Da qui il mio dubbio: qual è l'approccio corretto? C'è un qualche
>> principio
>> generale che non ho bene afferrato oppure va fatto revert di quel/quei
>> changeset?
>>
>
> Non credo siamo mai giunti ad una conclusione condivisa. Il mio umile
> parere è che la correzione (che ha unito i landuse) sia stata un'operazione
> scorretta e peggiorativa per la qualità del dato. In fondo è meglio avere
> informazioni (che in questo momento sono) inutili piuttosto che non averle,
> ed è peggio ancora distruggerle come ha fatto mcheckimport.
>
+1
Mi accodo anch'io nel dire che nel caso specifico non lo trovo corretto
proprio perché lì in mezzo, tra i due landuse, c'è un percorso che prima
era escluso (correttametne) e ora si trova rappresentato in mezzo ai filari.

Proprio in questi giorni sto cercando di mettere ordine ai landuse selvaggi
nella mia zona e mi sto facendo le stesse domande.
Sono d'accordo nel tenerli separati se c'è qualcosa di "sufficientemente
largo" in mezzo (tipicamente una strada).
Ma come comportarsi se un landuse è separato da un altro da un muro o da
una rete metallica? Si lasciano separati o si fa un multipoligono con un
lato come barrier?
O ancora: un parcheggio o un parco sono da considerare come landuse o
possono essere inclusi all'interno, ad esempio di un landuse=residential?

IMHO, come si è scritto tanto e come ha ribadito per ultimo Alessandro,
attaccare elementi come strade, fiumi ed edifici ad un landuse è sempre
sbagliato.
Forse questo è l'unico punto fermo che si sia raggiunto finora. :-p

Lorenzo

P.s.: Un'ultima provocazione: probabilmente la mailing list non è il posto
più pratico per trovare una linea guida a questo problema...
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Landuse (aridaje)

[Marco_T]

Max1234Ita wrote
> Chiedo lumi a Voi: disegnare (a mano) i singoli appezzamanti costa tempo
> ed impegno, così come riunirli...

Ciao,
in linea di massima sono daccordo con te e non condivido quella fusione.

Qui secondo me vedi un buon esempio di mappatura:
https://www.openstreetmap.org/#map=18/45.91442/12.89087

- landuse sempre autonomi: per permettere eventuali specificazioni di tag
farmland *produce che possono modificarsi di anno in anno;
- landuse autonomi e separati: quando esiste un elemento evidente di
separazione (capezzagne, strade, rogge...ma anche quando c'e' un vuoto
apprezzabile tra due colture che dimostra una volontà di tenerle separate);
- landuse autonomi contigui quando non c'e' un vuoto tra le colture ma è
evidente una diversità di sesto d'impianto, di qualità seminata, di periodo
di semina che possono far supporre anche una diversa proprietà.

In sintesi, nel caso dei landuse, spenderei qualche nodo in più per
dettagliare e facilitare la successiva gestione dei singoli apezzamenti,
mentre sarei propenso a non sprecare nodi per dettagliare ogni mezzo metro
fiumi o strade quando dritti (tranne ovviamente il caso in cui i nodi sevano
o siano predisposti per uno scopo, come dice Martin).

Saluti.

-- 
Marco_T



--
View this message in context: 
http://gis.19327.n8.nabble.com/Landuse-aridaje-tp5896633p5896655.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [OSM-talk-be] Digital Globe Images

[Thibaut Philippart]

Hello


The imagery seems to be also more recent than SPW (less than 1 year in LLN and 
Chaumont area ; I didn't check in other areas).


Yep, definitely useful !


Thibaut


On May 12, 2017 8:51 AM, joost schouppe  wrote:

Yes, they even seemed to prioritize areas which had no decent coverage at all. 
For example, I checked my "area of interest" in Bolivia, and there's a lot of 
new woods to map (I like to following the outline of civilization):


http://www.openstreetmap.org/#map=12/-17.3651/-65.2039


Tais just pointed out that in Congo as well, some places are now mapable that 
weren't before. So if you had some areas of interest that had bad imagery 
before, now you will probably have something better.


As for Belgium: the imagery seems to be much more recent than Bing, check for 
example here:


http://www.openstreetmap.org/edit#map=18/50.63689/4.17203


I for one am not going to use SPW imagery until we have a more official letter 
from them, so for my Walloon mapping, this is definitely useful.



-- 

Joost Schouppe

OpenStreetMap | Twitter | LinkedIn | Meetup

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

Re: [OSM-talk] Nominatim and waterway relations, broken?

[Sarah Hoffmann]

Hi,

On Thu, May 11, 2017 at 11:04:30AM -0700, Ben Discoe wrote:
> Nominatim has been able to find waterway relations for at least a
> couple years, now.
> 
> For example, if you search "Klamath River", Nominatim's top result is:
> https://www.openstreetmap.org/relation/3624126
> 
> Which is great.  But two days ago, I created another river:
> http://www.openstreetmap.org/relation/7232264
> 
> Searching Nominatim for "Spoon River" currently gives "No results found".
> 
> Supposedly, Nominatim's database delay is small (minutes, not days).
> Anyone know why it's failing to find a large, 2-day-old relation?

It's kind of a bug in Nominatim. The relation is there, see
http://nominatim.openstreetmap.org/details.php?osmtype=R=7232264
but search doesn't return it properly.

Feel free to stop reading here, but here are the boring details:

The problem is with the importance of the feature computed from the
wikipedia importance. It is lower than the default importance you
get without a wikipedia tag. Now what happens when you search for
the river is that it looks for the first couple of matching results
ordered by importance and it finds all the ways that make up the
relation (which are also correctly tagged with name=Spoon river)
because they have the higher default importance. Rechecking the
result it realises that all those ways are part of a waterway
relation and shouldn't be returned as separate results. So they
all get deleted again from the result list, leaving an empty list.
The relation you are looking for never makes it out of the database.
You can get it, if you ask for more results:
http://nominatim.openstreetmap.org/?q=spoon%20river=50

The proper fix is to remove the ways that make up the relation
from the search index. I'm not sure how simple that actually is. I'll
look into it. Progress can be tracked in
https://github.com/openstreetmap/Nominatim/issues/722

Kind regards

Sarah

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

Re: [Talk-it] Landuse (aridaje)

[Martin Koppenhoefer]

sent from a phone

> On 12. May 2017, at 11:05, Cascafico Giovanni  wrote:
> 
> Credo valga il principio di mappare la realtà e di "ecomonia": 
> 
> se i landuse sono adiacenti, appiccichiamoli: avremo una rappresentazione 
> realistica e risparmieremo nodi.


per me le geometrie distinte che rappresentano la divisione del territorio 
hanno un senso anche a prescindere dei tag attuali (che potrebbero essere il 
landuse uguale). Risparmiare nodi è una cosa che può fare chi vuole, nel suo 
estratto, non nel database comune (se i nodi "in più" hanno al meno un minimo 
contenuto in più, come per esempio una descrizione (anche minimamente) più 
accurata di una geometria, ma anche in prospettiva: mentre al solito non si 
mettono nodi intermedi in un segmento di strada dritta, potrebbe avere senso 
già metterli agli incroci anche se quest'ultimi non sono ancora mappati).

Togliere dettagli come per esempio unire singole aree con attualmente gli 
stessi tag per me non ha senso, anzi, appesantisce il db (con una nuova 
versione di tutti gli oggetti coinvolti), rende futuri operazioni e inserimento 
di particolari più onerose e quindi abbassa anche la probabilità di 
manutenzione e di accuratezza.


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

Re: [OSM-talk] Revisiting traffic control and traffic calming

[Paul Johnson]

On Fri, May 12, 2017 at 1:28 AM, Marc Gemis  wrote:

> On Fri, May 12, 2017 at 8:20 AM, Paul Johnson  wrote:
> >
> >> to: the collection of ways one can travel to after stopping/giving
> >> way/waiting for traffic signal. This would include the from way so
> >> u-turns have to obey the sign/signal as well.
> >
> >
> > Yes.  At a minimum, a stop, give_way, traffic_signals or traffic_calming
> > relation would have 1 from, 1 intersection and 1 to.
>
> Does that mean that for the examples on
> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals with
> at least 1 dual carriage way, one will need 4 relations ?


Simplest case, traffic signal impacts all movements, dual carriageway
north-south, single-carriageway east-west, you would have 1 relation with
four from, four to, and two intersection roles.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-it] Landuse (aridaje)

[Max1234Ita]

Ciao a tutti,
mi sorge un dubbio circa la mappatura dei landuse: di solito, tendo a
mapparli in modo da tenerli separati tra loro, ad esempio così: 
https://www.openstreetmap.org/#map=16/44.9821/9.1204=N
  

Oggi, però, tornando su un'area da me mappata qualche tempo fa (poco
distante da quella indicata sopra, tra l'altro), mi sono imbattuto in un
certo numero di oggetti come questo: 
https://www.openstreetmap.org/way/258756153/history#map=16/44.9768/9.0981=N

 
, che erano separati, seppur vicini, ma sono stati  "riappiccicati" agli
altri in uno o più changeset dal titolo "unito landuse leggermente
distaccati".

Se non ricordo male, qualche tempo fa, si era parlato di questa cosa qui in
lista, e ne era uscito il principio che tenere i landuse separati va bene
perché "descrive il territorio" (non trovo più il link, però). In questo
caso, si fosse trattato di un utente qualunque, avrei pensato al solito
Utente Pasticcione, e via con le rampogne... ma qui si tratta di
"mcheckimport": dubito fortemente che dietro questo nickname si celi
l'ultimo degli stupidi!

Da qui il mio dubbio: qual è l'approccio corretto? C'è un qualche principio
generale che non ho bene afferrato oppure va fatto revert di quel/quei
changeset? 

Chiedo lumi a Voi: disegnare (a mano) i singoli appezzamanti costa tempo ed
impegno, così come riunirli...

Grazie in anticipo!
Max



--
View this message in context: 
http://gis.19327.n8.nabble.com/Landuse-aridaje-tp5896633.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] Landuse (aridaje)

[Gianluca Boero]

Ciao...

io sono per disegnare a mano costi anche un'enormità di tempo ogni 
singolo appezzamento. In alcuni casi tra di un terreno e l'altro ci 
possono essere strade sterrate di accesso, canali, ogni elemento che di 
per se non è un landuse.


Poi dovrebbe valere la regola principale che non possono convivere due 
landuse, per cui se si disegna come landuse  una zona ed all'interno vi 
è un centro residenziale, quest'ultimo deve essere estrapolato e taggato 
diversamente.



Il 12/05/2017 09:53, Max1234Ita ha scritto:

Ciao a tutti,
mi sorge un dubbio circa la mappatura dei landuse: di solito, tendo a
mapparli in modo da tenerli separati tra loro, ad esempio così:
https://www.openstreetmap.org/#map=16/44.9821/9.1204=N


Oggi, però, tornando su un'area da me mappata qualche tempo fa (poco
distante da quella indicata sopra, tra l'altro), mi sono imbattuto in un
certo numero di oggetti come questo:
https://www.openstreetmap.org/way/258756153/history#map=16/44.9768/9.0981=N

, che erano separati, seppur vicini, ma sono stati  "riappiccicati" agli
altri in uno o più changeset dal titolo "unito landuse leggermente
distaccati".

Se non ricordo male, qualche tempo fa, si era parlato di questa cosa qui in
lista, e ne era uscito il principio che tenere i landuse separati va bene
perché "descrive il territorio" (non trovo più il link, però). In questo
caso, si fosse trattato di un utente qualunque, avrei pensato al solito
Utente Pasticcione, e via con le rampogne... ma qui si tratta di
"mcheckimport": dubito fortemente che dietro questo nickname si celi
l'ultimo degli stupidi!

Da qui il mio dubbio: qual è l'approccio corretto? C'è un qualche principio
generale che non ho bene afferrato oppure va fatto revert di quel/quei
changeset?

Chiedo lumi a Voi: disegnare (a mano) i singoli appezzamanti costa tempo ed
impegno, così come riunirli...

Grazie in anticipo!
Max



--
View this message in context: 
http://gis.19327.n8.nabble.com/Landuse-aridaje-tp5896633.html
Sent from the Italy General mailing list archive at Nabble.com.

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


--
Gianluca Boero


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

Re: [OSM-talk] Revisiting traffic control and traffic calming

[Paul Johnson]

On Fri, May 12, 2017 at 12:57 AM, Marc Gemis  wrote:

> So would a stop sign / give way sign /traffic signal then be mapped as
>
> stop_position: node where on the street does one have to stop/give
> way/wait for traffic signal
>

My thinking on this is stop_position isn't necessary as, unlike public
transportation, the distinction from the conflict point itself (the
intersection node(s)) isn't significant enough to bother.


> sign : node (optional) the exact location of the sign
>

I'd go with device instead, as this could potentially be a traffic signal.
Or on many intersections where a high traffic expressway crosses a minor
road, it could be multiple devices:  Traffic signals that is perpetually
flashing red for the minor way and flashing yellow for the trunk, in
addition to stop signs facing the minor directions.  This comes up a lot,
for example, on US 26 between Gresham and Government Camp, US 30 between
Portland and Warrenton, and pretty much any 70 MPH surface expressway in
Oklahoma.


> from: the way one is following to which the action has to be applied
> (is this needed ?)
>

Yes, but optional.  There could be multiple from ways.  For example, a four
way intersection for which there is a three-way stop, and one of those
directions may turn right without stopping.  Or a French example, a traffic
signal that has a "bicycles yield when turning right
"
sign.


> intersection: the node of the intersection for which the sign/signal holds
>

 Yes.

to: the collection of ways one can travel to after stopping/giving
> way/waiting for traffic signal. This would include the from way so
> u-turns have to obey the sign/signal as well.
>

Yes.  At a minimum, a stop, give_way, traffic_signals or traffic_calming
relation would have 1 from, 1 intersection and 1 to.


> is this how you see the relation ? Could it be simplified for the most
> common case that the sign/traffic signal applies to all directions one
> can travel ?
>

Yes.  A situation like an onramp meter
, onramp or similar yield sign,
or all-way stop where all possible movements for which the control or
calming applies is a single node, and all movements across that node are
affected by the calming or control, could still be mapped as just a simple
node with the current schema.


> what in case there is a turn restriction at the intersection ? Does
> the to-collection of the stop sign also have to include prohibited
> turns ?
>

No, you would use the existing turn restriction relation schema for turn
restrictions.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Landuse (aridaje)

[Simone Saviolo]

Il giorno 12 maggio 2017 09:53, Max1234Ita  ha
scritto:

> Da qui il mio dubbio: qual è l'approccio corretto? C'è un qualche principio
> generale che non ho bene afferrato oppure va fatto revert di quel/quei
> changeset?
>

Non credo siamo mai giunti ad una conclusione condivisa. Il mio umile
parere è che la correzione (che ha unito i landuse) sia stata un'operazione
scorretta e peggiorativa per la qualità del dato. In fondo è meglio avere
informazioni (che in questo momento sono) inutili piuttosto che non averle,
ed è peggio ancora distruggerle come ha fatto mcheckimport.

C'è chi dice che così facendo appesantiamo inutilmente il database. Ma non
stiamo creando un database geografico del mondo? ;-)

Ciao,

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

Re: [Talk-it] [tagging] start/goal ed altimentria in relazione

[mbranco]

Ne avevamo parlato qui [1] .

Il succo è :

/Nell'help online di waymarkedtrails [2] spiegano che per il profilo
altimetrico di default seguono lo sviluppo Ovest --> Est / Nord--> Sud
(chissà perchè non seguono l'ordine con cui sono elencate le varie
ways)/

Ciao,
  Marco

[1] http://gis.19327.n8.nabble.com/Direzione-relazioni-route-tp5891154.html
[2] https://hiking.waymarkedtrails.org/help/rendering/elevationprofiles



--
View this message in context: 
http://gis.19327.n8.nabble.com/tagging-start-goal-ed-altimentria-in-relazione-tp5896639p5896647.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [OSM-talk] Revisiting traffic control and traffic calming

[Marc Gemis]

So would a stop sign / give way sign /traffic signal then be mapped as

stop_position: node where on the street does one have to stop/give
way/wait for traffic signal
sign : node (optional) the exact location of the sign
from: the way one is following to which the action has to be applied
(is this needed ?)
intersection: the node of the intersection for which the sign/signal holds
to: the collection of ways one can travel to after stopping/giving
way/waiting for traffic signal. This would include the from way so
u-turns have to obey the sign/signal as well.

In general the to collection will be all ways leaving the
intersection, except for cases where right turns do not have to obey
the traffic signal, or where a right turn is give way and left +
straight ahead is stop.

is this how you see the relation ? Could it be simplified for the most
common case that the sign/traffic signal applies to all directions one
can travel ?
what in case there is a turn restriction at the intersection ? Does
the to-collection of the stop sign also have to include prohibited
turns ?

m.

On Thu, May 11, 2017 at 8:02 PM, Paul Johnson  wrote:
> On Thu, May 11, 2017 at 10:28 AM, Jean-Marc Liotier  wrote:
>>
>> On Sun, 7 May 2017 01:57:54 -0500
>> Paul Johnson  wrote:
>>
>> > I think it's time that we seriously reconsider how stop signs, yield
>> > signs and traffic calming devices are handled in all but the most
>> > simple (all approaches to the affected node apply) cases. [..] I'm
>> > thinking it's time to start mapping this similar to how we handle
>> > enforcement and turn restrictions, ie, with relations, for all but
>> > the simplest of cases, especially since the whole forward/backward
>> > direction=* thing is nonapplicable to nodes by design.
>>
>> Do you have in mind something like
>> https://wiki.openstreetmap.org/wiki/Relation:enforcement ?
>>
>> From the points of view of edition and data modeling, I believe that it
>> is the way forward.
>
>
> Yes, precisely.  It's at least a good starting point.
>
>>
>> From the point of view of data consumers, it requires grokking
>> relations - which is currently not common. Would that be a reason not
>> to choose that method ?
>
>
> I don't think so.  I consider Osmand to be the reference implementation for
> mobile navigation based off OSM data and it definitely understands
> enforcement relations.
>
> ___
> 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] Revisiting traffic control and traffic calming

[Paul Johnson]

On Fri, May 12, 2017 at 1:38 AM, Marc Gemis  wrote:

> ok, multiple from in a relation will solve this.
> Isn't it a problem that some "from"s do not end in some "intersection"s ?


Perhaps 3 intersection roles, with the single carriageway segment between
the dual carriageways being the third intersection role?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] weeklyOSM #355 02/05/2017-08/05/2017

[weeklyteam]

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

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

Enjoy!

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

[Talk-in] weeklyOSM #355 02/05/2017-08/05/2017

[weeklyteam]

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

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

Enjoy!

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

Re: [Talk-it] [tagging] start/goal ed altimentria in relazione

[Davide Sandona']

Lo vedo più un problema di waymarkedtrails. Potremo chiedere su github come
mai non utilizzano "from/to" e da lì valutare il da farsi.

Davide.

Il giorno 12 maggio 2017 10:54, Cascafico Giovanni  ha
scritto:

> Ciao,
>
> il sito waymarkedtrails.org sembra richiedere questi due tag per poter
> disegnare un profilo altimetrico nella direzione di marcia da destra a
> sinistra. JOSM validator mi segnala ruolo sconosciuto.
>
> In loro assenza può succedere che il profilo altimetrico sia rovesciato,
> cioè che non rispecchi quello definito dai tag approvati "from/to".
>
> Se confermata la necessità di "start/goal", mi sa da "mappare per il
> rendering". Visto che prossimamente ci sarà una mappatura o revisione di
> molti sentieri, con che criterio procedere?
>
>
> ___
> 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] Landuse (aridaje)

[Cascafico Giovanni]

Credo valga il principio di mappare la realtà e di "ecomonia":

se i landuse sono adiacenti, appiccichiamoli: avremo una rappresentazione
realistica e risparmieremo nodi.

se c'è qualsiasi cosa di rilevabile (waterway, highway, barrier...) non
appiccichiamoli.


Il giorno 12 maggio 2017 10:39, Simone Saviolo 
ha scritto:

> Il giorno 12 maggio 2017 09:53, Max1234Ita  ha
> scritto:
>
>> Da qui il mio dubbio: qual è l'approccio corretto? C'è un qualche
>> principio
>> generale che non ho bene afferrato oppure va fatto revert di quel/quei
>> changeset?
>>
>
> Non credo siamo mai giunti ad una conclusione condivisa. Il mio umile
> parere è che la correzione (che ha unito i landuse) sia stata un'operazione
> scorretta e peggiorativa per la qualità del dato. In fondo è meglio avere
> informazioni (che in questo momento sono) inutili piuttosto che non averle,
> ed è peggio ancora distruggerle come ha fatto mcheckimport.
>
> C'è chi dice che così facendo appesantiamo inutilmente il database. Ma non
> stiamo creando un database geografico del mondo? ;-)
>
> Ciao,
>
> Simone
>
> ___
> 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] [tagging] start/goal ed altimentria in relazione

[Cascafico Giovanni]

Ciao,

il sito waymarkedtrails.org sembra richiedere questi due tag per poter
disegnare un profilo altimetrico nella direzione di marcia da destra a
sinistra. JOSM validator mi segnala ruolo sconosciuto.

In loro assenza può succedere che il profilo altimetrico sia rovesciato,
cioè che non rispecchi quello definito dai tag approvati "from/to".

Se confermata la necessità di "start/goal", mi sa da "mappare per il
rendering". Visto che prossimamente ci sarà una mappatura o revisione di
molti sentieri, con che criterio procedere?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [tagging] start/goal ed altimentria in relazione

[Alfredo Gattai]

Dubito che possa diventare popolare questo genere di mappatura, e'
piuttosto onerosa, difficile da mantenere e credo anche difficile da
formalizzare.
Se lo implementano sul serio per facilitare il calcolo del profilo
altimetrico nel verso giusto se ne puo' riparlare ma probabilmente basta
semplicemente ordinare le way correttamente nel senso from/to per ogni
relazione e di dovrebbe ottenere lo stesso risultato.
Per quanto riguarda esportare un GPX con dei punti che abbiano un
significato, gli incroci li possono dedurre automaticamente come l'inizio e
la fine guardando il verso della relazione.

Alfredo


2017-05-12 10:54 GMT+02:00 Cascafico Giovanni :

> Ciao,
>
> il sito waymarkedtrails.org sembra richiedere questi due tag per poter
> disegnare un profilo altimetrico nella direzione di marcia da destra a
> sinistra. JOSM validator mi segnala ruolo sconosciuto.
>
> In loro assenza può succedere che il profilo altimetrico sia rovesciato,
> cioè che non rispecchi quello definito dai tag approvati "from/to".
>
> Se confermata la necessità di "start/goal", mi sa da "mappare per il
> rendering". Visto che prossimamente ci sarà una mappatura o revisione di
> molti sentieri, con che criterio procedere?
>
>
> ___
> 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] Revisiting traffic control and traffic calming

[Marc Gemis]

On Fri, May 12, 2017 at 8:20 AM, Paul Johnson  wrote:
>
>> to: the collection of ways one can travel to after stopping/giving
>> way/waiting for traffic signal. This would include the from way so
>> u-turns have to obey the sign/signal as well.
>
>
> Yes.  At a minimum, a stop, give_way, traffic_signals or traffic_calming
> relation would have 1 from, 1 intersection and 1 to.

Does that mean that for the examples on
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals with
at least 1 dual carriage way, one will need 4 relations ?

m

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

Re: [Talk-it] Landuse (aridaje)

[Martin Koppenhoefer]

sent from a phone

> On 12. May 2017, at 09:53, Max1234Ita  wrote:
> 
> Da qui il mio dubbio: qual è l'approccio corretto? C'è un qualche principio
> generale che non ho bene afferrato oppure va fatto revert di quel/quei
> changeset?


dipende dalla situazione: se i due oggetti (generalmente non importa il tipo di 
oggetto, finché sono aree, e non degli oggetti lineari come highway o puntuali) 
sono confinanti (hanno un confine in comune), allora vanno mappati con nodi in 
comune, invece se c'è qualcosa (anche piccolo) tra di loro, allora devi 
lasciare lo spazio. 

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

Re: [OSM-talk-be] Digital Globe Images

[Lionel Giard]

Yes it seems to be a little bit more recent than 2015 SPW imagery in
Chaumont area (like a few month between the two). But the main disadvantage
is that the pixel size seems to be higher in Digital Globe imagery (the
image looks coarser). Bing still is the clearest imagery of all (with the
high constrast that help recognize the items). Would like to get a recent
imagery of Wallonia with good contrast like Urbis or AGIV ahah.

2017-05-12 12:40 GMT+02:00 Thibaut Philippart 
:

> Hello
>
> The imagery seems to be also more recent than SPW (less than 1 year in LLN
> and Chaumont area ; I didn't check in other areas).
>
> Yep, definitely useful !
>
> Thibaut
>
> On May 12, 2017 8:51 AM, joost schouppe  wrote:
>
> Yes, they even seemed to prioritize areas which had no decent coverage at
> all. For example, I checked my "area of interest" in Bolivia, and there's a
> lot of new woods to map (I like to following the outline of civilization):
>
> http://www.openstreetmap.org/#map=12/-17.3651/-65.2039
>
> Tais just pointed out that in Congo as well, some places are now mapable
> that weren't before. So if you had some areas of interest that had bad
> imagery before, now you will probably have something better.
>
> As for Belgium: the imagery seems to be much more recent than Bing, check
> for example here:
>
> http://www.openstreetmap.org/edit#map=18/50.63689/4.17203
>
> I for one am not going to use SPW imagery until we have a more official
> letter from them, so for my Walloon mapping, this is definitely useful.
>
>
> --
> Joost Schouppe
> OpenStreetMap  |
> Twitter  | LinkedIn
>  | Meetup
> 
>
>
> ___
> 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

[OSM-talk] new Wikidata+OSM data in one RDF database

[Yuri Astrakhan]

TLDR: A SPARQL (rdf) database with both OSM and Wikidata data is up for
testing.  Allows massive cross-referenced queries between two datasets. The
service is a test, and needs a permanent home to stay alive.

Overpass Turbo is awesome, but sadly it does not have data from Wikidata,
nor does it support some SQL-like conditions. I have setup a temporary RDF
database that has both OSM & Wikidata. You can use SPARQL queries to find:

* All OSM objects with wikidata tag that references a Wikipedia
disambiguation page. Get the name of the page in first available language
ru, fr, de, en.http://tinyurl.com/mzlfb26

* OSM relations with wikidata tag pointing to a person (also tries multiple
language fallbacks).  http://tinyurl.com/m6fh3wx

* OSM relations with duplicate Wikidata IDs http://tinyurl.com/mvhhogx


== OSM data structure ==
osmnode, osmway, osmrel - OSM object prefix, e.g.  osmnode:1234
osmt - tag, e.g.  osmt:name:en  (only has tags with latin chars, -, _, :,
digits
osmm - meta data about the object -- type, isClosed, version.

I try to preserve OSM data without much changes. Every tag's value is
stored as a string, except for wikidata and wikipedia tags which are
converted to a URL, the same format as stored in Wikidata.

osmway:29453885
  osmt:name "Samina";
  osmt:waterway "river";
  osmt:wikidata wd:Q156065;
  osmt:wikipedia ;
  osmm:type "w";    could be "r", "w", and "n"
  osmm:isClosed false;     this meta property is only for OSM ways
  osmm:version 24.

Wikidata data structure is identical to https://query.wikidata.org (see
help)


== Current limitations ==
* Only includes OSM objects with either "wikidata" or "wikipedia" tags
* The OSM data only contains tags with only Latin letters, digits and
symbols - : _
* OSM geometry info is not imported, e.g. no center point or bounding box,
except for osmm:isClosed (true/false) property for ways.
* Does not include OSM object inheritance data - e.g. cannot query for
"find a node that is part of a way which is part of a relation that has
wikidata tag that ..."
* Wikidata is updated every second, but OSM does not yet update at all,
imported from a full db dump as of a few days ago.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Projet du mois - Panneaux électoraux

[Philippe Verdy]

Le 12 mai 2017 à 08:27, PanierAvide  a écrit :

>
>
Et malgré ce que tu sembles penser, non, faire des relations avec des
> centaines d'adresses ce n'est pas à la portée de tous les nouveaux
> contributeurs ;-)
>

J'ai dit tout le contraire ! Je n'ai pas du tout parlé de relation (sauf
concernant le découpage territorial que j'ai décrit à part comme une
seconde priorité mais en fait un projet séparé) mais juste de **noeuds**,
pas plus que ce qui est imprimé sur les cartes d'électeurs : une simple
adresse à géolocaliser et associer avec un tag donnant le numéro du bureau,
et pas forcément dans sa zone territoriale puisqu'effectivement ces zones
sont séprées quand elles existent, mais que les lieux de vote (qu'on
mettrait dans un "admin_centre" si on les mettait dans les relations à
créer séparément) sont souvent regroupés (et pas géolocalisés plsu
précisément que l'adresse, la position dans la salle ou même le bâtiment
n'ayant pas d'importance, pas plus qu'il est significatif de poser ce noeud
au centre de la porte d'entrée du point d'accès puisque souvent il y a
plusieurs accès et que les salles allouées dans les écoles par exemple
peuvent varier d'un scrutin à l'autre, mais normalement pas "l'adresse"
(c'est n'importe où dans une école ou dans une marie ou dans un centre
d'activité et de toute façon si c'est assez grand il y aura un fléchage
indicateurs provisoire sur place le jour du scrutin).
Poser ces noeuds est bien à la portée de toute le monde et toute l'année,
et cela ne demande aucune compétence dans les relations ou dans JOSM.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-es] Sobre el uso del prefijo "Wikiproyecto"

[dcapillae]

He abierto una conversación con los colaboradores del Wikiproyecto Perú que
puede resultar también interesante para los colaboradores del Wikiproyecto
España. La conversación viene al hilo de la necesidad de renombrar las
páginas del wikiproyecto para adaptarlas a las convenciones wikis. Podéis
seguir la conversación en la  página de discusión

  
del Wikiproyecto Perú.

En resumen, en primer lugar, se trata resolver el asunto del uso del
separador "/" en los nombres de subpáginas del wikiproyecto (esto no es
demasiado problema y se solucionará); en segundo lugar, está la cuestión del
prefijo "Wikiproyecto", cuyo uso está desaconsejado por la directrices
wikis, aunque es ampliamente utilizado.

¿Qué opináis? Las páginas del Wikiproyecto España utilizan este prefijo y
llevaría algo de tiempo renombrarlas todas. En el caso del Wikiproyecto
Perú, resultaría más sencillo porque tienen menos páginas. Les he propuesto
solucionar el problema del separador "/" y aprovechar la ocasión para
trasladar las páginas y subpáginas del Wikiproyecto Perú para hacerlas
depender de su correspondiente página de lugar, "ES:Perú", evitando tener
que utilizar el prefijo "Wikiproyecto" (desaconsejado). Esta sugerencia es
aplicable a cualquier otro proyecto de mapeo por territorio, incluido el
Wikiproyecto España.



-
Daniel Capilla
OSM user: dcapillae 
--
View this message in context: 
http://gis.19327.n8.nabble.com/Sobre-el-uso-del-prefijo-Wikiproyecto-tp5896672.html
Sent from the Spain mailing list archive at Nabble.com.

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

Re: [Talk-GB] [Imports] Importing fuel stations in UK and future similar imports

[Andrew Black]

> the "fair use" clause.
Which specific legislation are you referring to.

On 12 May 2017 17:10, "Ilya Zverev"  wrote:

> Hi everyone,
>
> First, I was amazed at the response. Thanks for constructive feedback,
> which I answer below, and no thanks for toxic responses, including asking
> for money (what money? We — as in maps.me — get none out of this) and
> imposing impossible restrictions (manually investigate context for each of
> thousands of points?). No import is perfect, and I cannot make this one too
> good for you. But it is pretty okay to me.
>
> I have refined the tag processing script. Removed name tags, changed
> postal_code to addr:postcode and formatted phone numbers according to the
> wikipedia table. "Navads" is appended to the source tag if present. I am
> not sure if I should add the brand:wikidata=Q154950 tag, and for now
> decided against that.
>
> You can see the updated result here: http://bl.ocks.org/Zverik/raw/
> ddcfaf2da25a3dfda00a3d93a62f218d/ (with OpenStreetMap and Satellite
> layers).
>
> Also I have started the wiki page: https://wiki.openstreetmap.
> org/wiki/Navads_Imports
>
> * Geocoding and accuracy: as I see on the map, all points in the dataset
> are placed properly on top of the fuel stations. The error based on OSM
> data is mostly inside 10 meters. I will ask NavAds for coordinate source
> for further datasets, but since most points are already in OSM, I think
> that would fall into the "fair use" clause. In this import, only 125 points
> are added as unmatched.
>
> * Other fuel stations inside 50 meters: I have found only one instance
> where the brand was changed. It is here: https://goo.gl/maps/9GLTVg1EWR82
> . The Street View from 2015 shows the BP station, but the map lists both BP
> and Shell. I assume the fuel station was overtaken in the past two years.
>
> Then I filtered fuel stations with the ref_distance > 30 meters (there are
> eight) and placed them on satellite imagery. Looks like that all of these
> are correct, and the big distances come from placement errors in OSM.
>
> * Official information vs on the ground: five objects have their opening
> hours changed. I assume Shell knows how their fuel stations work. Regarding
> other tags, only phone and addr:postcode replace OSM values (11 and 9
> changed); other tags, including operator, are preserved. In the Frederik's
> hypothetical example, the number of rooms will be added only if there are
> no such tag on the already existing hotel.
>
> * Freshness: Navads will update the data when Shell provides the update.
> It is as fresh as can be, but your changes to OSM won't be overwritten: if
> you saw opening hours changed, do update these. By the way, Robert's
> example about mismatch between opening hours on the Shell website and in
> the data is incorrect, I checked it and they match.
>
> * Five Ways Roundabout issue: I have forwarded that to NavAds. Also I
> asked them about links to branches (I cannot find any on the Shell website
> though) and names.
>
> * "The general view seems to be against IDs like this": what has happened
> with the principle "any tags you like"? Did we saturate the key space and
> not accepting new keys anymore? Can I read that "general view" documented
> anywhere? The "ref:navads_shell" key is the only one that is not verifiable
> on the ground, and is clearly added so the further updates do not have to
> rely on matching.
>
> Ilya
>
> > 12 мая 2017 г., в 1:22, Frederik Ramm  написал(а):
> >
> > Hi,
> >
> > On 05/11/2017 05:39 PM, Ilya Zverev wrote:
> >> Together with the NavAds company, we plan to import a thousand Shell
> >> fuel stations to the United Kingdom. The source is official, which
> >> means, Shell company specifically shared the dataset to put them on
> >> maps. Do you have any objections or questions?
> >
> > There are a couple other "we make your business visible on the map"
> > SEO-type businesses active in OSM, some better, some worse.
> >
> > Typical problems include:
> >
> > * Geocoding. We will want to know how the lat,lon pairs they use for
> > import have been generated. Sometimes the "official" source will
> > actually be based on measured GPS coordinates (good). Sometimes the
> > "official" source has simly geocoded their address with Google or HERE
> > (not admissible, license violation). Sometimes they have geocoded their
> > address with OpenStreetMap which is also bad because it can reinforce
> > errors or imprecisions - for example, if OSM has an address
> > interpolation range along a street, and a POI is placed with a specific
> > address at the computed interpolation point, then it looks like a
> > precise address but isn't.
> >
> > * Ignoring the area around the imported information. We want imports to
> > match the existing data; automatic conflation is often not enough. A POI
> > can end up in a house, a lake, or in the middle of a road, and if that
> > is not just a one-off but a systematic problem (of 

[talk-ph] weeklyOSM #355 02/05/2017-08/05/2017

[weeklyteam]

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

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

Enjoy!

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

Re: [Talk-GB] Proposed Import of UK Shell Filling Stations

[Dave F]

Apologies to Brian, who's clearly just passing on the message.


On 12/05/2017 00:58, Dave F wrote:

1. Wouldn't it be better to sort out your trees first?

2. What does ref_unused_tags.name refer to?

3. Are there any out of date stations that need removing/changing to 
another operator?


DaveF

On 11/05/2017 21:36, Brian Prangle wrote:

Hi everyone

There is a proposal for this import currently under discussion on the 
talk import mailing list and the OSMUK chapter has asked the proposer 
that it be discussed on the talk GB mailing list


Regards

Brian


___
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-es] Mapa de Galicia

[Jesús Gómez Fernández]

Pienso que la forma más sencilla para un comienzo es poder disponer de un
servicio WMS con esas capas para que puedan ser consultadas fácilmente
desde el editor JOSM [1]. Esto facilita comparar qué datos están ya en OSM
y cuáles no.

La importación de datos a OSM es un tema delicado porque requiere de
recursos y de una iniciativa que muchas veces la comunidad española de
OpenStreetmap no puede asumir. No hay que olvidar que aquí todos somos
voluntarios, nos movemos por intereses y que tampoco somos tantos los que
editamos de forma continua. No es lo mismo importar todas las farmacias de
Madrid o los número de portal de Zaragoza [2] que una base cartográfica
completa de una Comunidad Autónoma.
Dicho esto, me parece destacable el interés que vuestro Instituto tiene por
la apertura de los datos y su apoyo a OSM.

Independientemente de todo esto y como en otros casos, lo primero es que la
Consellería de un permiso expreso a la Fundación OpenStreetMap [3] para que
se pueda utilizar esas capas sin restricciones y de acuerdo a la licencia
Open Database Licence. [4][5]

Un saludo.
Jesús Gómez

[1] https://josm.openstreetmap.de/
[2] http://tareas.openstreetmap.es/
[3] https://drive.google.com/file/d/0B3PN5zfbzThqX0NNdFBDejE2RFE/view
[4]
https://wiki.openstreetmap.org/wiki/ES:Preguntas_frecuentes_legales#La_organizaci.C3.B3n_X_dispone_de_datos_para_su_descarga_gratuita_bajo_licencia_Y._.C2.BFSe_pueden_usar_en_OSM.3F
[5] https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility

El 10 de mayo de 2017, 9:19, Antonio de Arcos Rey <
antonio.dearcos@xunta.gal> escribió:

> Buenos días a todos:
>
>
>
>
>
> Lo primero es disculparme por no haber intervenido antes. Me ha resultado
> imposible participar en vuestro foro en tiempo real. La idea de ponerme en
> contacto con vosotros es porque desde la Xunta de Galicia nos gustaría
> compartir, siempre y cuando lo consideréis adecuado a vuestros propios
> intereses, nuestra última base cartográfica a  través de OSM. Se trata de
> una base continua a escala 1/10.000 que considero se adapta al trabajo
> colaborativo de los participantes del proyecto. Como es una cartografía que
> se extiende al ámbito de toda Galicia y que se solapa con el trabajo de los
> usuarios de la plataforma creemos que podría ser interesante tenerla como
> capa base en el modo edición, tal y como sucede con la capa del plan PNOA.
> Plan, en el que por cierto, participamos a medias con el IGN. Pero, estamos
> abiertos a otras ideas y sugerencias que nos podáis hacer.
>
>
>
> La cartografía la podéis consultar desde http://mapas.xunta.gal/
> visores/basico/ y seleccionando como mapa de fondo, el mapa base
> vectorial.
>
>
>
> He leído alguno de vuestros comentarios como:
>
>
>
>  *Imagino que os estáis refiriendo a cobrar a la Administración por los
> servicios de asistencia técnica en la importación de sus datos a OSM. ¿Cómo
> se gestiona eso? Entiendo que se debería hacer a través de un acuerdo entre
> la Administración y la Fundación OSM: la Fundación cobra los servicios y
> paga a los técnicos voluntarios. De lo contrario, sería un acuerdo entre la
> Administración y particulares.*
>
>
>
> Nos gustaría ayudar a la integración de nuestros datos, actualmente
> almacenados en una geodatabase, si nos decís cómo. La parte de aportación
> económica que algún miembro sugiere , la intentaríamos, pero no nos
> engañemos ,nos va a resultar más difícil de conseguir que mediante el
> trabajo del personal del Instituto. Aún así, yo lo intentaría transmitir a
> mis superiores.
>
>
>
>  Un saludo.
>
> Antonio de Arcos Rey
> *Xefe de Servizo de Coordinación e Información Territorial*
> *INSTITUTO DE ESTUDOS DO TERRITORIO*
> Consellería de Medio Ambiente, Territorio e Infraestruturas
> San Lázaro s/n
> 15707 Santiago de Compostela
> 981541751
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Comment relier un ensemble de polygones avec une liste d'identifiants

[HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI PERFORMANCE)]

Hello, 

En même temps, est ce qu'OSM n'a pas une pudeur de gazelle sachant que ces 
braves vigneron(ne)s ont des n° SIRET que l'on retrouve dans la base SIRENE, y 
compris sous leur forme patronymique, qui est sous licence libre ?
Même remarque concernant les professionnels de santé.

Mes 0,02 cl
Denis

-Message d'origine-
De : Vincent Bergeot [mailto:vinc...@bergeot.org] 
Envoyé : vendredi 12 mai 2017 12:13
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Comment relier un ensemble de polygones avec une 
liste d'identifiants

Bonjour,


Le 12/05/2017 à 11:14, Stéphane Péneau a écrit :
> Hello !
>
> Au sein d'une asso nouvellement créée  dans ma région, nous essayons, 
> entre autres activités, de donner un coup de main à des vignerons sur 
> la mise en valeur de leur exploitation dans le numérique.
>
> Une idée est de cartographier les parcelles de vigne et en y ajoutant 
> certaines informations comme le cépage, l'orientation des rangs, etc..
> (oui, OpenWines est dans le coup).
>
> Ensuite, on peut faire une petite carte avec umap pour que 
> l'exploitant puisse afficher sur son site web, une carte de ses 
> parcelles. C'est là que ça coince : si pour un vigneron, on peut aller 
> sélectionner à la main les parcelles qu'il gère, ça n'est pas vraiment 
> envisageable à plus grande échelle.
>
> Il faut trouver un moyen d'extraire automatiquement toutes les 
> parcelles de vigne du domaine x ou y.
>
> Je souhaite éviter d'indiquer "domaine du bon vin" comme "operator", 
> car on est un peu trop proche de données à caractère personnel.

Nous essayons également d'avancer la dessus dans le bordelais, à la fois sur 
les chais-domaines et les vignes.

Je n'avais pas pensé que le nom de domaine viticole puisse être une donnée à 
caractère personnel (d'ailleurs souvent complexe car il y a le nom de domaine, 
le nom que porte l'entreprise commerciale, ...). C'est effectivement la piste 
que j'imaginais comme tag sur la vigne car c'est bien l'exploitant de cette 
vigne.



> J'ai pensé ajouter le numéro cadastral de la parcelle du type 
> ref:FR:casastre=Z42.
> À partir de là, on peut faire une requête avec une liste de ref et de 
> commune.
>
> Il me semble que si nous n'avions pas forcément le droit d'indiquer 
> ces n° de parcelles, c'est en train de changer.
>
> Qu'en pensez-vous ? Une autre idée ? Une objection ?

curieux des réponses aussi :)

un autre thème pour le sotm-fr, autour d'un verre!




>
> Stéphane
>
>
> ___
> 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
---
Ce message et toutes les pièces jointes sont établis à l'intention exclusive de 
ses destinataires et sont confidentiels. L'intégrité de ce message n'étant pas 
assurée sur Internet, la SNCF ne peut être tenue responsable des altérations 
qui pourraient se produire sur son contenu. Toute publication, utilisation, 
reproduction, ou diffusion, même partielle, non autorisée préalablement par la 
SNCF, est strictement interdite. Si vous n'êtes pas le destinataire de ce 
message, merci d'en avertir immédiatement l'expéditeur et de le détruire.
---
This message and any attachments are intended solely for the addressees and are 
confidential. SNCF may not be held responsible for their contents whose 
accuracy and completeness cannot be guaranteed over the Internet. Unauthorized 
use, disclosure, distribution, copying, or any part thereof is strictly 
prohibited. If you are not the intended recipient of this message, please 
notify the sender immediately and delete it. 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Comment relier un ensemble de polygones avec une liste d'identifiants

[Christian Quest]

Le 12 mai 2017 à 11:14, Stéphane Péneau  a
écrit :

> Je souhaite éviter d'indiquer "domaine du bon vin" comme "operator", car
> on est un peu trop proche de données à caractère personnel. J'ai pensé
> ajouter le numéro cadastral de la parcelle du type ref:FR:casastre=Z42.
> À partir de là, on peut faire une requête avec une liste de ref et de
> commune.
>
> Il me semble que si nous n'avions pas forcément le droit d'indiquer ces n°
> de parcelles, c'est en train de changer.
>
> Qu'en pensez-vous ? Une autre idée ? Une objection ?
>

Il n'y a rien à ma connaissance qui empêche d'indiquer des numéros de
parcelles... si ce n'est notre capacité à maintenir à jour ces infos ;)

C'est une "information publique" au regard du code des Relations entre le
Public et l'Administration (CRPA pour les habitués), sa ré-utilisation est
libre... tous les textes réglementaires récents vont dans ce sens.

De plus, le plan cadastral fait partie des 9 jeux de données du Service
Public de la Donnée de Référence et l'objectif est bien que ces
identifiants soient utilisés partout où c'est utile pour permettre de
savoir qu'on parle bien du même objet entre 2 bases.

Par contre, la DGFiP n'a pas encore publié ses données... le seul absent à
ce jour sur les 9 jeux de données de référence.

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

Re: [Talk-GB] Proposed Import of UK Shell Filling Stations

[Frederik Ramm]

Dave,

On 12.05.2017 01:58, Dave F wrote:
> 1. Wouldn't it be better to sort out your trees first?

It's not OSM-UK that proposes this import; Brian has only pointed out
that there's a discussion going on. The import has been proposed by
commercial entities NavAds (who publicize store locations for retail
chains as a service) and Mail.ru (the company behind maps.me).

Bye
Frederik

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

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

[OSRM-talk] Docker/AWS installation question

[Neil J. McLeish]

Hi all.
Is this the place to ask if anyone can advise on setting up the docker bundle 
on an Elastic Beanstalk container on AWS?

I attempted it last week, and although it started out ok, I got a timeout error 
and it failed.

Here's what the log says:

[Instance: i-0d489e3f422ff2221] Command failed on instance. Return code: 1 
Output: (TRUNCATED)...non-zero code: 1 Failed to build Docker image 
aws_beanstalk/staging-app: treams boost-thread libgomp lua5.1 expat && rm -rf 
/src /opt/stxxl /usr/local/bin/stxxl_tool /usr/local/lib/libosrm*' returned a 
non-zero code: 1. Check snapshot logs for details. Hook 
/opt/elasticbeanstalk/hooks/appdeploy/pre/03build.sh failed. For more detail, 
check /var/log/eb-activity.log using console or EB CLI.


Thanks in advance for any advice/tips etc.

Neil.

[cid:image003.png@01D239BC.F4B170B0]

Neil McLeish | Software Development Engineer
Email: neil.mcle...@rgsit.com | Tel: 0845 8550 
550 | Web: www.rgsit.com



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

[Talk-tr] TR-GR sınırı

[Roman Neumüller]

Adam dün yeni üye olmuş ve ilk yaptığı iş Türkiye-Yunanistan sınırları  
kurçaladı:


https://www.openstreetmap.org/user/OSMANcoşkun/history

Benim şu anda vaktım yok - birisi lütfen kontrol edebilir mi ?

slm
Roman

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

Re: [OSM-talk-fr] Comment relier un ensemble de polygones avec une liste d'identifiants

[Vincent Bergeot]

Bonjour,


Le 12/05/2017 à 11:14, Stéphane Péneau a écrit :

Hello !

Au sein d'une asso nouvellement créée  dans ma région, nous essayons, 
entre autres activités, de donner un coup de main à des vignerons sur 
la mise en valeur de leur exploitation dans le numérique.


Une idée est de cartographier les parcelles de vigne et en y ajoutant 
certaines informations comme le cépage, l'orientation des rangs, etc.. 
(oui, OpenWines est dans le coup).


Ensuite, on peut faire une petite carte avec umap pour que 
l'exploitant puisse afficher sur son site web, une carte de ses 
parcelles. C'est là que ça coince : si pour un vigneron, on peut aller 
sélectionner à la main les parcelles qu'il gère, ça n'est pas vraiment 
envisageable à plus grande échelle.


Il faut trouver un moyen d'extraire automatiquement toutes les 
parcelles de vigne du domaine x ou y.


Je souhaite éviter d'indiquer "domaine du bon vin" comme "operator", 
car on est un peu trop proche de données à caractère personnel.


Nous essayons également d'avancer la dessus dans le bordelais, à la fois 
sur les chais-domaines et les vignes.


Je n'avais pas pensé que le nom de domaine viticole puisse être une 
donnée à caractère personnel (d'ailleurs souvent complexe car il y a le 
nom de domaine, le nom que porte l'entreprise commerciale, ...). C'est 
effectivement la piste que j'imaginais comme tag sur la vigne car c'est 
bien l'exploitant de cette vigne.




J'ai pensé ajouter le numéro cadastral de la parcelle du type 
ref:FR:casastre=Z42.
À partir de là, on peut faire une requête avec une liste de ref et de 
commune.


Il me semble que si nous n'avions pas forcément le droit d'indiquer 
ces n° de parcelles, c'est en train de changer.


Qu'en pensez-vous ? Une autre idée ? Une objection ?


curieux des réponses aussi :)

un autre thème pour le sotm-fr, autour d'un verre!






Stéphane


___
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] Comment relier un ensemble de polygones avec une liste d'identifiants

[Stéphane Péneau]

Le 12/05/2017 à 12:13, Vincent Bergeot a écrit :
Nous essayons également d'avancer la dessus dans le bordelais, à la 
fois sur les chais-domaines et les vignes.


Je n'avais pas pensé que le nom de domaine viticole puisse être une 
donnée à caractère personnel (d'ailleurs souvent complexe car il y a 
le nom de domaine, le nom que porte l'entreprise commerciale, ...). 
C'est effectivement la piste que j'imaginais comme tag sur la vigne 
car c'est bien l'exploitant de cette vigne.
J'ai essayé d'imaginer les différents cas qui posent problème avec cette 
solution :
- Le vigneron qui veut la carte de ses vignes, mais pas son nom dans Osm 
(certaines exploitations portent parfois nom+prénom de l'exploitant)
Afficher ce nom sur le chai est une chose, et utile s'il y a de la vente 
directe, mais indiquer l'emplacement de ses parcelles en est une autre.


- Celui qui est ok avec le nom du domaine dans Osm, puis qui change 
d'avis quelque temps plus tard : il devra aller le supprimer 
manuellement dans Osm, et et il restera toujours une trace dans 
l'historique. Alors que si la liaison se fait depuis une autre 
référence, alors il lui suffira de supprimer sa carte umap.




un autre thème pour le sotm-fr, autour d'un verre!


:-)

Stf

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

[Talk-gb-westmidlands] West Midlands Data Discovery Centre

[Brian Prangle]

Hi everyone

Take a look at this amazing facility which is a development of our work
locally with ODI,Birmingham Innovation Centre and Deft351. It's still only
a demonstrator, developed by Opendatasoft, but I'm pretty impressed with
its visualisation capabilities

https://datadiscoverycenter.opendatasoft.com/pages/homepage/


Regards

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

Re: [Talk-lv] Pamatu tagošana - redux

[Vitaly Bolshakov]

Sveiki!

Tā, kā oficiālas shēmas priekš pamatiem pagaidām nav, nebezjēdzīgi ir  
atzīmēt ar building=foundation . Pasaulē ir atzīmētas, 492 tādas ēkas,  
pārsvarā Polijā, Viduseiropā, un 7 no tām Latvijā :)


Bet, domāju, ja ēkā ir celtniecības stadijā lietderīgāk tagot  
"construction", bet drupu stāvoklī ir pieņemts "ruins".


Ar cieņu, Vitālijs

On Fri, 12 May 2017 10:09:09 +0300, pec...@gmail.com   
wrote:


Es arī. Problēma tāda, ka neizskatās ka tas ir kaut kādā veidā  
nostiprinājies OSM Wiki. Tāpēc vaicāju ka tīkla gudrība ir kaut ko citu  
radījusi vietā :)


Pagaidām paliku pie foundation

Tagoju Tukumu no jaunajām Globe bildēm ja kas.

Pēteris.


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

Re: [Talk-GB] Public Rights of Way data for Cambridgeshire

[Adam Snape]

I would be interested to add rights of way information closer to home
(Lancashire).

Dave refers to the long list of other councils that have released row
information. Is this the rowmaps website or is it somewhere on osm that I'm
missing?

The information on rowmaps is not clear. Is all of the data on there
compatible with osm?

Adam

On 11 May 2017 8:25 p.m., "John Aldridge"  wrote:

> One bit of feedback, from a first try at doing this for real: footpaths
> often cross parish boundaries, and at least in this area change their
> reference when they do so. But your slippy map only displays geometry for a
> single parish at a time, meaning that tracking the prow_ref value for the
> full length of a single path can take a lot of navigation within your tool.
>
> Would it be hard to display geometry for all ROWs overlapping the current
> slippy map extent, whichever parish they are from?
>
> --
> Cheers,
> John
>
> ___
> 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-africa] weeklyOSM #355 02/05/2017-08/05/2017

[weeklyteam]

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

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

Enjoy!

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

Re: [Talk-lv] Pamatu tagošana - redux

[pec...@gmail.com]

Es arī. Problēma tāda, ka neizskatās ka tas ir kaut kādā veidā
nostiprinājies OSM Wiki. Tāpēc vaicāju ka tīkla gudrība ir kaut ko citu
radījusi vietā :)

Pagaidām paliku pie foundation

Tagoju Tukumu no jaunajām Globe bildēm ja kas.

Pēteris.

2017. gada 11. maijs 23:33 Viesturs Zarins  rakstīja:

> Pēdējo reizi lietoju building=construction
> Bet jau daudz ūdeņu aiztecejis.
>
> On Wed, May 10, 2017, 23:06 pec...@gmail.com  wrote:
>
>> Sveiki!
>>
>> Kā mūsdienās tagojam pamatus OSMā?
>>
>> Paldies,
>> Pēteris.
>> ___
>> Talk-lv mailing list
>> Talk-lv@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-lv
>>
>


-- 
mortigi tempo
Pēteris Krišjānis
___
Talk-lv mailing list
Talk-lv@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lv

Re: [Talk-se] ID översättningar

[Tobias Wrede]

I Tyskland hade vi samma diskussionen. "path" översettades till "Pfad" 
vilken har samma meningen som svensk "stig" ("något mindre is skogen") 
men inte något some är cycle- eller gångväg i stan. Men hw=path infördes 
precis att ersätta hw=footway och hw=cycleway  i obestämda situationer 
(https://wiki.openstreetmap.org/wiki/Approved_features/Path).


 Tysk begreppet för path i ID är nu "Mehrzweckweg" (flerfunktionsväg?) 
vilket inte alls är något meningsfull men är lite bättre som missledande 
"Pfad".


Jag tror hw=path är etablerad nu för både den mindre stigen in skogen 
och den vanlig gångväg i stan. Surface, width, smoothness etc. användas 
för att bättre bestämmer vilken sorts sig/väg det är egentligen.


/Tobi

Am 11.05.2017 um 18:49 schrieb M Branting:


Det är nog ingen bra idé att tagga naturstigar på samma sätt som breda 
gc-banor. Att skyltade cykelbanor för taggas cyclelway är väl 
självklart. Mindre uppenbart är det med de vanliga gång och 
cykelvägarna (gc-banorna). Om man betraktar dem som cykelbanor där 
även gångtrafik är tillåten så kan man tagga dem som cyclelway med 
foot=yes


Jag håller alltså med om att path (stig) bör reserveras för 
(natur)stigar . Här är istället frågan om avgränsningen mot ”bruksväg” 
(track) som av någon obegriplig anledning översatts till ”ej 
underhållen bruksväg”.


Skickades från E-post  
för Windows 10


*Från: *Mattias Dalkvist 
*Skickat: *den 11 maj 2017 18:14
*Till: *OpenStreetMap Sverige mailinglista 


*Ämne: *[Talk-se] ID översättningar

Hej

I ID så är highway=path översatt med stig vilket de många förknippar 
med något mindre i skogen, inte alls lika generellt som det Engelska 
uttrycket.


Ett av de rekommenderade sätten att tagga gång- och cykelbanor är ju 
highway=path med  foot=designated och bicycle=designated och jag har 
sätt flera nybörjare som ändrar dem till footway. Har också sätt några 
som satt highway=footway och highway=cycleway


Någon som kan komma på något bättre än Stig?

Det ända jag kommer på är något i stil med "Stig, gång- & cykelväg" 
vilket inte är så bra ;)


--

Dalkvist



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



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

[OSM-talk-fr] Comment relier un ensemble de polygones avec une liste d'identifiants

[Stéphane Péneau]

Hello !

Au sein d'une asso nouvellement créée  dans ma région, nous essayons, 
entre autres activités, de donner un coup de main à des vignerons sur la 
mise en valeur de leur exploitation dans le numérique.


Une idée est de cartographier les parcelles de vigne et en y ajoutant 
certaines informations comme le cépage, l'orientation des rangs, etc.. 
(oui, OpenWines est dans le coup).


Ensuite, on peut faire une petite carte avec umap pour que l'exploitant 
puisse afficher sur son site web, une carte de ses parcelles. C'est là 
que ça coince : si pour un vigneron, on peut aller sélectionner à la 
main les parcelles qu'il gère, ça n'est pas vraiment envisageable à plus 
grande échelle.


Il faut trouver un moyen d'extraire automatiquement toutes les parcelles 
de vigne du domaine x ou y.


Je souhaite éviter d'indiquer "domaine du bon vin" comme "operator", car 
on est un peu trop proche de données à caractère personnel. J'ai pensé 
ajouter le numéro cadastral de la parcelle du type ref:FR:casastre=Z42.
À partir de là, on peut faire une requête avec une liste de ref et de 
commune.


Il me semble que si nous n'avions pas forcément le droit d'indiquer ces 
n° de parcelles, c'est en train de changer.


Qu'en pensez-vous ? Une autre idée ? Une objection ?

Stéphane


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

Re: [Talk-GB] Proposed Import of UK Shell Filling Stations

[Robert Whittaker (OSM lists)]

On 11 May 2017 at 23:25, Frederik Ramm  wrote:
> Link to discussion so far on imports@:
> https://lists.openstreetmap.org/pipermail/imports/2017-May/004956.html
>
>> My concern would be from where to they get their geocoding.  Most
>> businesses, and particularly chain businesses, tend to use postcode
>> centroids, which are not accurate enough, probably get them from Google.
>
> I voiced the same general concern, but a random sample I checked of the
> (actually rather few) stations that are proposed to be newly added
> seemed to be impeccably placed.

In which case, there is a different concern: have they done their
geo-coding from an acceptable source for use in OSM? If they've e.g.
used Address Base (or a similar product) or got coordinates from a
non-OpenData OS map, then there could be problems. I think we need
more information on the data sources here.

Some other comments:

* If a ref/id is to be used, it should probably be Shell's branch
reference number, not that of the third-party data provider. (These do
exist, and at least in some cases are verifiable on the ground, as
I've found at least one on a pump at a Shell garage up the road from
me.)

* There's an addressing edge-case error on a station near me, which is
located on the Five Ways Roundabout near Mildenhall:
http://www.openstreetmap.org/way/478902268 . We currently have
(incorrectly) "addr:place=5 Ways Roundabout", but the script is
proposing adding "addr:street=Ways Roundabout" and
"addr:housenumber=5".

* The script shouldn't just add source=Navads to objects it's only
modifying, as that would imply the whole object was sourced from
there. If existing tags and position are retained, then this needs to
be acknowledged somehow. If there's an existing source tag, then
Navads could just be added to the list (I haven't checked to see if
this is the case). If not, then there's more of a challenge. The
script current just adds source=Navads in this case. I think the
importers need to propose a better solution for this.

* As others have said, there needs to be more information about what
happens if there are multiple amenity=fuel objects within 50m, and
also what happens if any existing tags conflict with what the script
would like to add.

* The proposed website tag appears to point to http://www.shell.co.uk
for all the branches. Would it be better pointing to a specific URL
for that branch (assuming this exists)?

* The opening_hours from the import script for
http://www.openstreetmap.org/way/248030653 don't match those displayed
on Shell's own website for the same station. One as open till 11pm on
Saturday, the other only 10pm. So is the data accurate / up-to-date?

Robert.

-- 
Robert Whittaker

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

Re: [Talk-lv] Pamatu tagošana - redux

[Maris Nartiss]

Labā ziņa, ka Tukumā tā bilde sēž metra robežās - var droši zīmēt.
Paskatījos gan tikai stacijas apkārtni.

Māris.


2017. gada 12. maijs 10:09 pec...@gmail.com  rakstīja:
> Es arī. Problēma tāda, ka neizskatās ka tas ir kaut kādā veidā
> nostiprinājies OSM Wiki. Tāpēc vaicāju ka tīkla gudrība ir kaut ko citu
> radījusi vietā :)
>
> Pagaidām paliku pie foundation
>
> Tagoju Tukumu no jaunajām Globe bildēm ja kas.
>
> Pēteris.
>
> 2017. gada 11. maijs 23:33 Viesturs Zarins  rakstīja:
>>
>> Pēdējo reizi lietoju building=construction
>> Bet jau daudz ūdeņu aiztecejis.
>>
>>
>> On Wed, May 10, 2017, 23:06 pec...@gmail.com  wrote:
>>>
>>> Sveiki!
>>>
>>> Kā mūsdienās tagojam pamatus OSMā?
>>>
>>> Paldies,
>>> Pēteris.
>>> ___
>>> Talk-lv mailing list
>>> Talk-lv@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-lv
>
>
>
>
> --
> mortigi tempo
> Pēteris Krišjānis
>
> ___
> Talk-lv mailing list
> Talk-lv@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lv
>

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

Re: [Talk-GB] Proposed Import of UK Shell Filling Stations

[Jez Nicholson]

for background info: a couple of links about Navads and what they do for
Shell (and other brands)
http://www.prweb.com/releases/navads/shell/prweb13779126.htm and
https://navads.eu/businesslistings/

It would be interesting for OSM[UK] to be an official recipient of
up-to-date, clean data if indeed it is proved to be clean enough for import.

On Fri, 12 May 2017 at 08:59 Robert Whittaker (OSM lists) <
robert.whittaker+...@gmail.com> wrote:

> On 11 May 2017 at 23:25, Frederik Ramm  wrote:
> > Link to discussion so far on imports@:
> > https://lists.openstreetmap.org/pipermail/imports/2017-May/004956.html
> >
> >> My concern would be from where to they get their geocoding.  Most
> >> businesses, and particularly chain businesses, tend to use postcode
> >> centroids, which are not accurate enough, probably get them from Google.
> >
> > I voiced the same general concern, but a random sample I checked of the
> > (actually rather few) stations that are proposed to be newly added
> > seemed to be impeccably placed.
>
> In which case, there is a different concern: have they done their
> geo-coding from an acceptable source for use in OSM? If they've e.g.
> used Address Base (or a similar product) or got coordinates from a
> non-OpenData OS map, then there could be problems. I think we need
> more information on the data sources here.
>
> Some other comments:
>
> * If a ref/id is to be used, it should probably be Shell's branch
> reference number, not that of the third-party data provider. (These do
> exist, and at least in some cases are verifiable on the ground, as
> I've found at least one on a pump at a Shell garage up the road from
> me.)
>
> * There's an addressing edge-case error on a station near me, which is
> located on the Five Ways Roundabout near Mildenhall:
> http://www.openstreetmap.org/way/478902268 . We currently have
> (incorrectly) "addr:place=5 Ways Roundabout", but the script is
> proposing adding "addr:street=Ways Roundabout" and
> "addr:housenumber=5".
>
> * The script shouldn't just add source=Navads to objects it's only
> modifying, as that would imply the whole object was sourced from
> there. If existing tags and position are retained, then this needs to
> be acknowledged somehow. If there's an existing source tag, then
> Navads could just be added to the list (I haven't checked to see if
> this is the case). If not, then there's more of a challenge. The
> script current just adds source=Navads in this case. I think the
> importers need to propose a better solution for this.
>
> * As others have said, there needs to be more information about what
> happens if there are multiple amenity=fuel objects within 50m, and
> also what happens if any existing tags conflict with what the script
> would like to add.
>
> * The proposed website tag appears to point to http://www.shell.co.uk
> for all the branches. Would it be better pointing to a specific URL
> for that branch (assuming this exists)?
>
> * The opening_hours from the import script for
> http://www.openstreetmap.org/way/248030653 don't match those displayed
> on Shell's own website for the same station. One as open till 11pm on
> Saturday, the other only 10pm. So is the data accurate / up-to-date?
>
> Robert.
>
> --
> Robert Whittaker
>
> ___
> 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-it-lazio] Fw: Walk4art II appuntamento: lunedì 8 maggio ore 17.00 a Piazza Niccolò Copernico

[Marcello Pelato]

 On Friday, May 12, 2017 11:04 AM, Marcello Pelato  
wrote:
 

 Per me con anticipo perché non Sabato 27/05/2017 o 03/05/2017?Eh?


 

On Wednesday, May 10, 2017 2:28 PM, Luca Moiana  
wrote:
 

 Ok per inizio Giugno, per me sarebbe meglio di Sab pomeriggio 
A presto L




   

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

Re: [Talk-lt] Paprastas duomenų pildymas su StreetComplete

[JurKis]

Puikumėlis. Išbandžiau, paprastumas labai patiko. Tik reiktų po Upload
Answerpaspaudimo įdėti kokį laikroduką/ratuką/pranešimą - kitaip neina
suprati, išsiųsti pakeitimai ar ne.

2017-05-12 12:17 GMT+03:00 Tomas Straupis :

> Sveiki
>
>   Pabandžiau ypatingai paprastą programėlę StreetComplete. Jos pagalba
> bet kas, net neturintis absoliučiai jokio supratimo apie OSM žymas,
> gali puikiai pildyti trūkstamą informaciją žaidimo pavidalu. Plačiau
> tinklaraštyje:
>
>   https://blog.openmap.lt/2017/05/12/duomenu-pildymas-
> naudojant-street-complete/
>
> P.S. Darbo laikas, pavadinimai ir dangos - labai naudinga. Visa kita
> labiau žaidimas... :-)
>
> --
> Tomas
>
> ___
> Talk-lt mailing list
> Talk-lt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lt
>
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt

Re: [OSM-talk-fr] Projet du mois - Panneaux électoraux

[PanierAvide]

Oui la complexité ne vient pas de poser le bureau en lui-même (quoiqu'il 
faut déjà connaître les tags à y ajouter, amenity=polling_station 
d'après le wiki ? La documentation est soit cachée soit minimaliste).
Je faisais surtout référence aux contours (ce qui à priori est le plus 
intéressant à représenter sur une carte). Et malgré ce que tu sembles 
penser, non, faire des relations avec des centaines d'adresses ce n'est 
pas à la portée de tous les nouveaux contributeurs ;-) En tout cas pas 
avec les outils génériques type JOSM. Si on a un outil dédié à cette 
tâche où l'affectation d'une adresse à un bureau de vote peut se faire 
en un clic, à travers une interface compréhensible, là oui on pourra 
dire que c'est facile à faire.
L'avantage d'un outil de la sorte c'est que ça pourrait resservir sur 
d'autres tâches : associer un point adresse à une relation de rue, les 
arrêts de bus à une ligne...


Cordialement,

Adrien.

Le 11/05/2017 à 21:38, Philippe Verdy a écrit :
Les bureaux de votes ce sont **avant tout** des points. Le découpage 
territorial c'est effectivement plus complexe mais on devrait y 
**déjà** avoir tous les noeuds d'adresse et ce n'est CERTAINEMENT PAS 
plus compliqué, donc à la portée de tout le monde et tout au long de 
l'année.


De plus je pense qu'il y a bien plus que 60 000 panneaux (même pas 
deux panneaux par commune alors que même les moins peuplées et les 
plus rurales ont plusieurs bourgs, et sont généralement très étendues, 
avec des centres d'activité ou salles communales ou aires sportives 
trop dispersées pour se contenter juste de la seule place de la 
mairie, où ne se concentre pas qu'une petite partie de l'activité et 
même des résidents...).


On doit être plus près du double en réalité (le data.gouv.fr 
 est partiel et je pense juste fondé sur la 
précision par les communes d'au moins une adresse par bureau). Les 
panneaux obéissent tout de même à une logique de proximité et de 
publicité même pour les électeurs les plus éloignés du bureau qu'il 
faut aussi rappeler de venir: avoir un deuxième panneau devient une 
nécessité si la population dépasse les 1000 habitants ou si la 
distance maximale vers le bureau dépasse les 5 km et qu'il y a des 
résidents hors des centre-bourgs, ou dans un bourg secondaire d'une 
ancienne commune fusionnée mais dans une agglomération non limitrophe, 
pour que la moyenne des électeurs informés par panneau posé dépasse un 
seuil minimal de ~200 électeurs.


(ce n'est pas rien dans les résultats d'un bureau si on doit tenir 
compte aussi de l'opinion de la population rurale avec une information 
suffisante, sachant qu'un même bureau ne dépasse normalement pas les 
1000 inscrits et est souvent autour des 700 à 800, mais moins 
évidemment dans les communes à bureau unique: si dans ces communes il 
y a seulement 200 inscrits mais moins de 100 dans le centre-bourg et 
le reste dispersé et très éloigné du lieu de vote, il est normal 
d'ajouter un panneau décentralisé même si un second bureau n'est pas 
ouvert, même si dans le bourg secondaire il n'y a pas plus de 50 
habitants): c'est peut-être moins important pour les élections 
nationales (où l'information publique est largement disponible aussi 
sur d'autres médias), mais pour les élections locales (communales) 
c'est essentiel sinon les habitants éloignés ne se sentent pas 
représentés ou se sentiront ignorés des décisions du conseil municipal 
si la campagne officielle les a tout bonnement ignorés.



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



--
PanierAvide
Géomaticien & développeur

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

Re: [OSM-talk-fr] Comment bien tagguer les cabinets médicaux ?

[Benoit Fournier]

On May 11, 2017 11:50 PM, "Christian Rogel" <
christian.ro...@club-internet.fr> wrote:
>
>
> > Le 2017 Mae 11 à 22:07, Christian Quest  a
écrit :
> >
> > On a déja eu une discussion similaire, ne vous étonnez pas si je
ressort les mêmes arguments ;)
> >
> > Les médecins ou avocats (et quelques autres professions), sont
réglementés et n'ont pas la possibilité de faire de publicité.
> > Les noms posent aussi le problème non pas de la vie privée, mais de la
donnée à caractère personnel.
> >
> > A mon avis, on peut mapper un cabinet médical et indiquer son nom
lorsqu'il n'est pas personnel (c'est une enseigne), mais ajouter le nom du
médecin n'apporte pas grand chose de plus, OSM n'étant pas un annuaire et
ça évite les deux sujets précédents. L'important est surtout de savoir qu'à
cet endroit se trouve un service médical.
> >
> > Les marques et enseignes qui se basent sur un nom de personne (pour un
commerce), sont un choix et ne posent pas de problème en terme de donnée à
caractère personnel ni de publicité.
>
> Je n’arrive pas à détecter le caractère personnel d’une donnée qui est
publiée : c’est comme taire le nom de l’auteur d’un livre.
> Sur quel texte, ou jurisprudence vous basez-vous pour affirmer ce qui va
à l’encontre de la réalité perceptible ?

Pour une donnée à caractère personnel (surtout si elle est publiée), on
peut s'appuyer sur une définition de la CNIL, pour avoir un point de départ
commun. Dans sa version simple :
https://www.cnil.fr/fr/definition/donnee-personnelle
"Toute information identifiant directement ou indirectement une personne
physique"
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-us] weeklyOSM #355 02/05/2017-08/05/2017

[weeklyteam]

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

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

Enjoy!

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

[Talk-GB] weeklyOSM #355 02/05/2017-08/05/2017

[weeklyteam]

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

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

Enjoy!

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

[Talk-ca] weeklyOSM #355 02/05/2017-08/05/2017

[weeklyteam]

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

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

Enjoy!

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

Re: [OSM-talk-fr] Projet du mois - Panneaux électoraux

[PanierAvide]

Mea culpa, j'ai dû mal comprendre. Du coup quels sont les tags en 
pratique pour les bureaux de vote ? Vu qu'il semble il y avoir plusieurs 
méthodes :

- amenity=polling_station + ref=*
- polling_station=yes + polling_station:ref=*
- amenity=polling_station + polling_station=

Admettons que l'on voudrait créer un thème MapContrib pour ajouter ces 
points de bureaux de vote (pour simplifier la tâche), il faut au minimum 
s'accorder sur les tags.


Cordialement,

Adrien.

Le 13/05/2017 à 01:06, Philippe Verdy a écrit :



Le 12 mai 2017 à 08:27, PanierAvide > a écrit :



Et malgré ce que tu sembles penser, non, faire des relations avec
des centaines d'adresses ce n'est pas à la portée de tous les
nouveaux contributeurs ;-)


J'ai dit tout le contraire ! Je n'ai pas du tout parlé de relation 
(sauf concernant le découpage territorial que j'ai décrit à part comme 
une seconde priorité mais en fait un projet séparé) mais juste de 
**noeuds**, pas plus que ce qui est imprimé sur les cartes d'électeurs 
: une simple adresse à géolocaliser et associer avec un tag donnant le 
numéro du bureau, et pas forcément dans sa zone territoriale 
puisqu'effectivement ces zones sont séprées quand elles existent, mais 
que les lieux de vote (qu'on mettrait dans un "admin_centre" si on les 
mettait dans les relations à créer séparément) sont souvent regroupés 
(et pas géolocalisés plsu précisément que l'adresse, la position dans 
la salle ou même le bâtiment n'ayant pas d'importance, pas plus qu'il 
est significatif de poser ce noeud au centre de la porte d'entrée du 
point d'accès puisque souvent il y a plusieurs accès et que les salles 
allouées dans les écoles par exemple peuvent varier d'un scrutin à 
l'autre, mais normalement pas "l'adresse" (c'est n'importe où dans une 
école ou dans une marie ou dans un centre d'activité et de toute façon 
si c'est assez grand il y aura un fléchage indicateurs provisoire sur 
place le jour du scrutin).
Poser ces noeuds est bien à la portée de toute le monde et toute 
l'année, et cela ne demande aucune compétence dans les relations ou 
dans JOSM.



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



--
PanierAvide
Géomaticien & développeur

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

Re: [Talk-pt] Parque Marinho Professor Luiz Saldanha

[Marcos Oliveira]

O editor original já reverteu essa alteração.



No dia 11 de maio de 2017 às 23:18, Topo Lusitania Lusitania <
topolusita...@yahoo.com> escreveu:

> Caros
>
> Foram hoje convertido para "footway" os limites exteriores do Parque
> Marinho Professor Luiz Saldanha.
>
> Quase de certeza um recém chegado bem intencionado quis desenhar ou
> aperfeiçoar um caminho e foi atraiçoado pela "selva" (desculpem a
> expressão) de multipoligonos na zona, cuja compreensão até para nós é
> algumas vezes difícil.
>
> Fomos os primeiros a desenhar o referido parque com os limites de
> acessibilidade às embarcações, limites cuidadosamente seguidos pela leitura
> de Leis e não pela importação fácil de ficheiros del precisão questionáve,
> se bem que fornecidos por organismos oficiais. Estes limites de
> acessibilidade há muito desapareceram, apagados por quem julga que os
> multipoligonos são o melhor para o OSM. e que uma linha desenhada deve
> cumprir trezentas funções...
>
> Se queremos que mais pessoas mapeiem, devemos procurar que o que
> desenhamos seja de fácil compreensão para os recém chegados.
>
> Esta discussão já é "velha" no OSM, mas nós sempre preferimos o "KISS"
> americano ao "Ósculo" latino
>
> Desculpem o desabafo
>
> A equipa TopoLusitania
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
>


-- 
Um Abraço,
Marcos Oliveira
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [Talk-br] Dúvida sobre nova versão do editor iD

[Adriano Rosa]

seguindo as dicas do wille, realmente, fica mais fácil do jeito atual.
porém, ivaldo, como vc prefere o uso do mouse ao invés do teclado, o
negócio é treinar para usar o botão direito. a única coisa que você não
pode fazer é deixar de mapear. ;D

On Fri, May 12, 2017 at 12:36 AM Pedro vida torta 
wrote:

> Pelo contrario ficou mais produtivo, agora a caixinha só aparece qdo VC
> quer evitando ficar na frente do elemento a ser editado , principalmente na
> inserção de numeração de vias.
>
> Em 10/05/2017 13:29, "Ivaldo Nunes de Magalhães" 
> escreveu:
>
>> Saudações!
>>
>> Acessei hoje o OSM para editar via iD Editor e percebi que ele não está
>> abrindo mais automaticamente a caixinha de ferramentas flutuante quando se
>> clica nos elementos do mapa.
>>
>> Agora é necessário clicar com o botão direito do mouse/touch para ter
>> acesso às opções.
>>
>> Alguém pode me confirmar se vai se manter assim? Pois fica muito
>> improdutivo.
>>
>>
>> Atte. Ivaldo 
>> ​ (user OSM: ivaldonm​)
>>
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
-- 

cordialmente,

adriano.

_
Sempre tenha os seus arquivos quando você precisar deles com @Dropbox. Conta
 de 2GB é grátis!

Acesse: http://db.tt/enaEb5F
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-cz] Cyklistický mapathon PrahouNaKole 15.května (toto pondělí)

[Jan Martinec]

Ahoj,

asi víte, že v pondělí pořádá Prahou Na Kole první cyklomapathon:
"Chcete pomoci s vytvářením nejpodrobnější cyklistické mapy Prahy?"
Na FB padl dotaz (V.Filler), "dorazí i někdo z OSM komunity, kdo by nás 
případně informoval o novinkách ve stavu OSM, které je při zákresu cyklo 
třeba respektovat?"


Nuže - jsou vůbec takové novinky? Skoro mám dojem, že velkým tahounem 
českého cykloOSM je právě PnK, a kromě toho mi připadá, že je tenhle typ 
tagování poměrně stabilní; možná JOSM má širší builtin bicycle_parking 
presety, ale to je za poslední dobu medle všechno.


(Já se tam možná vyskytnu.)
Mapování zdar,
HPM

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

semanárioOSM Nº 355 02/05/2017-08/05/2017

[weeklyteam]

Bom dia,

O semanárioOSM Nº 355, o resumo de tudo o que acontece no mundo OpenStreetMap, 
está publicado *em português*:

http://www.weeklyosm.eu/pb/archives/9055/

Aproveite!

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

Re: [OSM-talk-fr] Comment bien tagguer les cabinets médicaux ?

[Christian Rogel]

> Le 2017 Mae 12 à 09:09, Benoit Fournier  a écrit :
> 
> On May 11, 2017 11:50 PM, "Christian Rogel"  > wrote:
> >
> >
> > > Le 2017 Mae 11 à 22:07, Christian Quest  > > > a écrit :
> > >
> > > On a déja eu une discussion similaire, ne vous étonnez pas si je ressort 
> > > les mêmes arguments ;)
> > >
> > > Les médecins ou avocats (et quelques autres professions), sont 
> > > réglementés et n'ont pas la possibilité de faire de publicité.
> > > Les noms posent aussi le problème non pas de la vie privée, mais de la 
> > > donnée à caractère personnel.
> > >
> > > A mon avis, on peut mapper un cabinet médical et indiquer son nom 
> > > lorsqu'il n'est pas personnel (c'est une enseigne), mais ajouter le nom 
> > > du médecin n'apporte pas grand chose de plus, OSM n'étant pas un annuaire 
> > > et ça évite les deux sujets précédents. L'important est surtout de savoir 
> > > qu'à cet endroit se trouve un service médical.
> > >
> > > Les marques et enseignes qui se basent sur un nom de personne (pour un 
> > > commerce), sont un choix et ne posent pas de problème en terme de donnée 
> > > à caractère personnel ni de publicité.
> >
> > Je n’arrive pas à détecter le caractère personnel d’une donnée qui est 
> > publiée : c’est comme taire le nom de l’auteur d’un livre.
> > Sur quel texte, ou jurisprudence vous basez-vous pour affirmer ce qui va à 
> > l’encontre de la réalité perceptible ?
> 
> Pour une donnée à caractère personnel (surtout si elle est publiée), on peut 
> s'appuyer sur une définition de la CNIL, pour avoir un point de départ 
> commun. Dans sa version simple :
> https://www.cnil.fr/fr/definition/donnee-personnelle 
> 
> "Toute information identifiant directement ou indirectement une personne 
> physique"
> 
> 


Si la CNIL dit qu’un nom personnel est une donnée personnelle, elle a raison, 
mais ce n’est guère qu’une tautologie. On n’avance pas.

Il est légal de constituer une base de données des auteurs de publication (j’ai 
passé une fraction de mon temps professionnel à la faire, le fichier étant, 
bien sûr, déclaré à la CNIL).
Visser une plaque visible depuis le domaine public est un acte de publication 
et en faire une BDD est légal.
Il est légal de faire une base de données à partir de ce que j’ai publié en 
impression ou par Internet. Mais, si le fichier est publié, j’ai un droit de 
regard et c’est tout.

L’intention ne compte pas et doit être traitée sur le même plan que tout autre 
nom personnel circulant dans l’espace physique public (marque, nom de commerce, 
nom d’immeuble).
Dans notre cas, c’est une question qui doit être régulée entre la Fondation OSM 
et la version anglaise de la CNIL.


Christian R.

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

Re: [Talk-cz] [OpenStreetMap] Miroslav Suchý vyřešil jednu z vašich poznámek

[Jan Martinec]

Dne 11.5.2017 v 21:33 Karel Volný napsal(a):

čusbus,

jak doprčic udělám z bodu poznámky bod v mapě?

když se přepnu na iD, tak mi zmizí

is it just me or ... to se ten krám ani nedá donutit zobrazit souřadnice, když
už neumí převést poznámku na bod?

K.


Ahoj,

asi nedá. iD je hlavně _jednoduchý_ editor; zobrazovat více vrstev 
najednou se mi moc nedařilo. Doporučil bych JOSM - tam sice note přímo 
na bod nezkonvertuju, ale aspoň se a) dostanu k souřadnicím, i b) můžu 
si zobrazit více vrstev naráz.


Vede k těm ruinám i nějaká pěšina, nebo je to úplně zarostlý a opuštěný?
http://www.openstreetmap.org/node/4848368158

Zdar,
Honza Piškvor Martinec

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

Re: [OSM-talk-fr] Comment bien tagguer les cabinets médicaux ?

[sly (sylvain letuffe)]

Salut,


cquest wrote
> Les médecins ou avocats (et quelques autres professions), sont réglementés
> et n'ont pas la possibilité de faire de publicité.

Pour savoir si c'est autorisé, le mieux c'est de s'en référer aux organismes
qui édictent les règles pour ces professions réglementées.
Pour les médecins, le Conseil national de l'Ordre des médecins semble le bon
endroit pour chercher.
Article 80 :
https://www.conseil-national.medecin.fr/article/article-80-libelle-des-annuaires-304
**
Les seules indications qu'un médecin est autorisé à faire figurer dans les
annuaires à usage du public, quel qu'en soit le support, sont :

1°) ses nom, prénoms, adresse professionnelle, numéros de téléphone et de
télécopie, jours et heures de consultations ;
2°) sa situation vis-à-vis des organismes d'assurance-maladie ;
3°) la qualification qui lui aura été reconnue conformément au règlement de
qualification, les diplômes d'études spécialisées complémentaires et les
capacités dont il est titulaire.
**

De ce que je comprend, c'est autorisé. Avec son nom et son prénom.


cquest wrote
> OSM n'étant pas un annuaire

Je crois donc que la question est principalement là :
OSM peut-il et a-t-il vocation à devenir un annuaire ?
J'ai envie de dire qu'avec tous les magasins référencé avec
contact:phone/email/adresse/website/... et rangé par catégories (tag) c'est
déjà le cas dans les faits (y'a qu'a se rappeler des pros qui commencent à
remplir la base de ça !).
Est-ce bien, je ne sais pas.
D'un coté OSM ajoute la localisation, c'est là sa force. D'un autre, oui, ça
existe déjà ailleurs (en libre pour les médecins disait christian), et ça va
être dur de maintenir à jour. 

Perso, ça ne me choque pas de voir OSM devenir un annuaire géolocalisé en
plus d'une base géo (qui donc dit avec certitude que osm n'ai pas/ne devrait
pas être un annuaire ?). 
Maintenant si dans le cas des professions de santé, c'est pas à jour, c'est
mieux et libre ailleurs, peut-être faut il écrire quelque part et donner la
source. Mais ça ne justifie, il ne me semble pas, de crier haro sur ceux qui
en font la saisie. OSM, ce me semble, ça a toujours été : si tu en vois
l'intérêt et que l'outil le permet, saisie le !

Corollaire : je m'opposerais (pas la discussion) aux actions de ceux qui,
décidant que ça ne doit pas y être, le supprime de la base pendant que
d'autres le mettent.





-
-- 
sly, contact direct : sylvain /a\ letuffe o r g
http://wiki.openstreetmap.org/wiki/User:Sletuffe
--
View this message in context: 
http://gis.19327.n8.nabble.com/Comment-bien-tagguer-les-cabinets-medicaux-tp5896325p5896659.html
Sent from the France mailing list archive at Nabble.com.

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

[Talk-dk] hurtige bygninger

[Michel Coene]

Det  er nu muligt lynhurtig at mappe bygninger, små søer og skove i JOSM.
Jeg har lavet en lille vejledning her:
https://wiki.openstreetmap.org/wiki/Da:Byginger
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-cz] duplicitní budovy

[jzvc]

Dne 9.5.2017 v 21:52 Jan Macura napsal(a):

Svého času jsem k tomu sepsal (pouze mnou) doporučený postup na wiki:
https://wiki.openstreetmap.org/wiki/Cs:R%C3%9AIAN/p%C5%99etrasov%C3%A1n%C3%AD
Anžto se nikdo nevyjádřil, že by nesouhlasil. Doporučuji tak postupovat.


Cus,

tak pokud by se ti chtelo, mel bys do postupu doplnit vyuziti pointInfo 
a jeho ikonky brouka ;D. Tzn budovy ktery neexistujou nebo maji nejaky 
problem nareportovat, on je pak traser pokud vim znova ani nenatrasuje 
(ty co nestojej).




H.

2017-05-08 21:23 GMT+02:00 >:

Nikdy jsem importy z RUIANu nedělal. Může mi někdo znalejší říct,
jak se přistupuje k místům, kde budovy jsou už ručně zadané?



On 18.4.2017 20:05, Milan Cerny wrote:

Díky za opravu. Alespoň že se povedlo vymazat ty duplicitní
budovy. Ostatních chyb je tam stejně, jako na většině území ČR.
Jen by mě zajímalo, proč jsou budovy po jednotlivých importech
odsazeny o cca 0,2 m.
Pokud je zdroj dat i postup stejný, měly by být budovy přesně na
sobě. Kdyby se tak stalo, hned by to nějaký checker odhalil.
S tím odsazením to v klidu prošlo.

Milan


Od: majka >
Komu: OpenStreetMap Czech Republic
>
Datum: 18.04.2017 18:05
Předmět: Re: [Talk-cz] duplicitní budovy

Tak se zrovna nahrává oprava, ty duplicitní budovy jsou
vymazané.

Celou oblast by to chtělo ještě detailně projít - JOSM tam
vyhazuje spoustu
chyb.

Něco jsem opravila, něco by chtělo prohlédnout na místě,
něco by mělo
stačit od počítače, ale po menších územích po částech. Podle
mě jsou tam
nechané importy s jejich chybami (křížící se vodní cesty a
silnice, křížící
se silnice bez křižovatek, silnice končící přilepením v
oblasti , nějaké
duplicity v landuse apod., nedostatečně otagované věci - jen
komentář...).
Zatím jsem jen hodila "potoky" pod zem tam, kde jednoznačně
žádné nejsou na
povrchu, "odlepila" most od řeky a podobně... V RUIANu toho
moc není, ale
spousta dalších budov by se dala vzít podle katastrální mapy.

Můžu se časem pokusit na dálku opravit co půjde, ale chtělo
by to raději
někoho místního.

Majka

2017-04-18 11:23 GMT+02:00 Janda Martin >:

Dobry den,

to vypada ze jsme se paralelne upravili stejnou
oblast. Nejsem si jisty
jestli v te dobe spravne fungovala detekce kolizi mezi
changesety. Muj
changeset je 43764373.

 M

--
*From: *"majka" >
*To: *"OpenStreetMap Czech Republic"
>
*Sent: *Tuesday, April 18, 2017 11:11:32 AM
*Subject: *Re: [Talk-cz] duplicitní budovy

Jestli je zájem, můžu to odpoledne udělat.
Vzhledem k tomu, že je to skoro půl roku staré a
netuším, jestli tam není
něco novějšího, navrhuju to udělat napůl ručně, bez
revertu. Stáhnu do
JOSM, hromadně vymažu všechny budovy jednoho uživatele
(asi si hodím
korunou čí), a případně domapuju chybějící podle RUIAN...

Majka

2017-04-18 10:05 GMT+02:00 Milan Cerny
>:

Ahoj, dnes jsem narazil na oblast, kde jsou téměř
všechny budovy dvojitě,
tedy jedna přes druhou.
Oba changesety (import RUIAN) jsou ze stejného dne i
hodiny. Je nějaká
možnost, jak se toho zbavit jinak než ručně? Je to
asi 800 objektů.
Ideálně revert ale s tím nemám žádné zkušenosti, tak
jestli by někdo
pomohl.

Díky.

Milan


https://www.openstreetmap.org/changeset/43764373#map=13/49.8931/14.8521



https://www.openstreetmap.org/changeset/43764573#map=13/49.8931/14.8521
 

Re: [Talk-GB] [Imports] Importing fuel stations in UK and future similar imports

[Ilya Zverev]

Hi everyone,

First, I was amazed at the response. Thanks for constructive feedback, which I 
answer below, and no thanks for toxic responses, including asking for money 
(what money? We — as in maps.me — get none out of this) and imposing impossible 
restrictions (manually investigate context for each of thousands of points?). 
No import is perfect, and I cannot make this one too good for you. But it is 
pretty okay to me.

I have refined the tag processing script. Removed name tags, changed 
postal_code to addr:postcode and formatted phone numbers according to the 
wikipedia table. "Navads" is appended to the source tag if present. I am not 
sure if I should add the brand:wikidata=Q154950 tag, and for now decided 
against that.

You can see the updated result here: 
http://bl.ocks.org/Zverik/raw/ddcfaf2da25a3dfda00a3d93a62f218d/ (with 
OpenStreetMap and Satellite layers).

Also I have started the wiki page: 
https://wiki.openstreetmap.org/wiki/Navads_Imports

* Geocoding and accuracy: as I see on the map, all points in the dataset are 
placed properly on top of the fuel stations. The error based on OSM data is 
mostly inside 10 meters. I will ask NavAds for coordinate source for further 
datasets, but since most points are already in OSM, I think that would fall 
into the "fair use" clause. In this import, only 125 points are added as 
unmatched.

* Other fuel stations inside 50 meters: I have found only one instance where 
the brand was changed. It is here: https://goo.gl/maps/9GLTVg1EWR82 . The 
Street View from 2015 shows the BP station, but the map lists both BP and 
Shell. I assume the fuel station was overtaken in the past two years.

Then I filtered fuel stations with the ref_distance > 30 meters (there are 
eight) and placed them on satellite imagery. Looks like that all of these are 
correct, and the big distances come from placement errors in OSM.

* Official information vs on the ground: five objects have their opening hours 
changed. I assume Shell knows how their fuel stations work. Regarding other 
tags, only phone and addr:postcode replace OSM values (11 and 9 changed); other 
tags, including operator, are preserved. In the Frederik's hypothetical 
example, the number of rooms will be added only if there are no such tag on the 
already existing hotel.

* Freshness: Navads will update the data when Shell provides the update. It is 
as fresh as can be, but your changes to OSM won't be overwritten: if you saw 
opening hours changed, do update these. By the way, Robert's example about 
mismatch between opening hours on the Shell website and in the data is 
incorrect, I checked it and they match.

* Five Ways Roundabout issue: I have forwarded that to NavAds. Also I asked 
them about links to branches (I cannot find any on the Shell website though) 
and names.

* "The general view seems to be against IDs like this": what has happened with 
the principle "any tags you like"? Did we saturate the key space and not 
accepting new keys anymore? Can I read that "general view" documented anywhere? 
The "ref:navads_shell" key is the only one that is not verifiable on the 
ground, and is clearly added so the further updates do not have to rely on 
matching.

Ilya

> 12 мая 2017 г., в 1:22, Frederik Ramm  написал(а):
> 
> Hi,
> 
> On 05/11/2017 05:39 PM, Ilya Zverev wrote:
>> Together with the NavAds company, we plan to import a thousand Shell
>> fuel stations to the United Kingdom. The source is official, which
>> means, Shell company specifically shared the dataset to put them on
>> maps. Do you have any objections or questions?
> 
> There are a couple other "we make your business visible on the map"
> SEO-type businesses active in OSM, some better, some worse.
> 
> Typical problems include:
> 
> * Geocoding. We will want to know how the lat,lon pairs they use for
> import have been generated. Sometimes the "official" source will
> actually be based on measured GPS coordinates (good). Sometimes the
> "official" source has simly geocoded their address with Google or HERE
> (not admissible, license violation). Sometimes they have geocoded their
> address with OpenStreetMap which is also bad because it can reinforce
> errors or imprecisions - for example, if OSM has an address
> interpolation range along a street, and a POI is placed with a specific
> address at the computed interpolation point, then it looks like a
> precise address but isn't.
> 
> * Ignoring the area around the imported information. We want imports to
> match the existing data; automatic conflation is often not enough. A POI
> can end up in a house, a lake, or in the middle of a road, and if that
> is not just a one-off but a systematic problem (of the "let's dump our
> stuff into OSM and the community can then fix it" kind) then it is
> reason enough to revert the whole import and ask the importer to go back
> to the drawing board.
> 
> * Mismatch between "official" data and reality. Especially for larger
> chains 

Re: [Talk-pt] Parque Marinho Professor Luiz Saldanha

[Topo Lusitania Lusitania]

Bom diaDe facto a situação foi corrigida, mas não pelo editor original.O Parque 
Marinho Professor Luiz Saldanha foi inicialmente desenhado muito antes de 2016 
(antes das importações massivas) por outros colaboradores, e as suas 
colaborações foram pura e simplesmente apagadas. A nossa contribuição para este 
parque foi, no minimo a de delimitar as zonas de navegação existentes 
(interdita, restrita, etc.) Essa colaboração (anterior a 2016) pura e 
simplesmente desapareceu. E fizémo-lo porque para além do Openstreetmap também 
colaboramos no http://www.openseamap.org/

Não queremos iniciar na lista nenhuma "flame". Limitamo-nos a constactar 
factos. E por nós este assunto morre aqui.
 CumprimentosA equipa TopoLusitania

  From: Marcos Oliveira 
 To: Topo Lusitania Lusitania ; OSM Portugal 
 
 Sent: Friday, May 12, 2017 2:38 PM
 Subject: Re: [Talk-pt] Parque Marinho Professor Luiz Saldanha
   
O editor original já reverteu essa alteração.


No dia 11 de maio de 2017 às 23:18, Topo Lusitania Lusitania 
 escreveu:

Caros
Foram hoje convertido para "footway" os limites exteriores do Parque Marinho 
Professor Luiz Saldanha.
Quase de certeza um recém chegado bem intencionado quis desenhar ou aperfeiçoar 
um caminho e foi atraiçoado pela "selva" (desculpem a expressão) de 
multipoligonos na zona, cuja compreensão até para nós é algumas vezes difícil.
Fomos os primeiros a desenhar o referido parque com os limites de 
acessibilidade às embarcações, limites cuidadosamente seguidos pela leitura de 
Leis e não pela importação fácil de ficheiros del precisão questionáve, se bem 
que fornecidos por organismos oficiais. Estes limites de acessibilidade há 
muito desapareceram, apagados por quem julga que os multipoligonos são o melhor 
para o OSM. e que uma linha desenhada deve cumprir trezentas funções...

Se queremos que mais pessoas mapeiem, devemos procurar que o que desenhamos 
seja de fácil compreensão para os recém chegados.
Esta discussão já é "velha" no OSM, mas nós sempre preferimos o "KISS" 
americano ao "Ósculo" latino

Desculpem o desabafo
 A equipa TopoLusitania
__ _
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap. org/listinfo/talk-pt





-- 
Um Abraço,
Marcos Oliveira


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

[Talk-pe] Renombrado de subpáginas del wikiproyecto según convenciones wikis

[Johnattan Rupire]

Hola!

Daniel Capilla, nos envía este mensaje por twitter [0] proponiéndonos el 
renombrado de las páginas de la wiki referentes a Perú [1]. Lo dejo por 
aquí para recibir sus comentarios.


[0] https://twitter.com/dcapillae/status/861170233037529088

[1] https://wiki.openstreetmap.org/wiki/ES_talk:Wikiproyecto_Per%C3%BA

Saludos!


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

Re: [Talk-GB] [Imports] Importing fuel stations in UK and future similar imports

[Andy Mabbett]

On 12 May 2017 at 17:08, Ilya Zverev  wrote:

> I am not sure if I should add the brand:wikidata=Q154950 tag, and for now 
> decided against that.

I would encourage you to include this.

> * "The general view seems to be against IDs like this": what has happened 
> with the principle "any tags you like"?

I see no reason you should not include this data as originally
proposed. Anyone suspicious of it, or who does not recognise it, can
ignore it.

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

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

Re: [Talk-GB] [Imports] Importing fuel stations in UK and future similar imports

[Philip Barnes]

A few issues I have spotted with the proposed data,

Website: This should only be included if it refers to the actual object
and should not be set to the shell.co.uk site.

I have spotted some really silly street names, such as
addr:street=A46/A6 A46/A6 Trunk Road.

A filling station is often part of something larger such as
highway=services, in that case many of the tags i.e. postcode/phone
number belong on the higher level object, not the filling station. 

Service Areas often have more than one filling station, one for cars
and bikes and another for HGVs.

Phil (trigpoint)

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