Re: [Talk-in] Talk-in Digest, Vol 110, Issue 1

[Saikat Maiti]

Hello Nikhil,

Glad to here about your plan. I am Saikat from Navi Mumbai and we have a
small team based on New Panvel (recently organized MESMapathon
). Please let me
know if you need any help with mapping using JOSM or iD editor. Our team
will be happy to be a part of your initiative.

Looking forward to hear from you.


Thanks,
Saikat

On Tue, Oct 3, 2017 at 5:30 PM,  wrote:

> Send Talk-in mailing list submissions to
> talk-in@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-in
> or, via email, send a message with subject or body 'help' to
> talk-in-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-in-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-in digest..."
>
>
> Today's Topics:
>
>1. Planning for OSM mapping party in Pune for Maharashtra (Nikhil VJ)
>2. Re: Planning for OSM mapping party in Pune for Maharashtra
>   (Chandan Baba)
>
>
> --
>
> Message: 1
> Date: Tue, 3 Oct 2017 00:26:22 +0530
> From: Nikhil VJ 
> To: talk-in , datameet
> 
> Subject: [Talk-in] Planning for OSM mapping party in Pune for
> Maharashtra
> Message-ID:
> 

Re: [OSM-talk] A thought on bot edits

[Warin]

On 06-Oct-17 02:37 PM, JB wrote:


Le 05/10/2017 à 22:50, Yuri Astrakhan a écrit :
I like the "bot=no" flag, or a more specific one for a given field -  
"name:en:bot=no" - as long as those flags are not added by a bot :)

Ho…
We are now manually contributing one more tag to say it was 
contributed manually…
So many people seem to think one geodatabase can be created only 
through bots, imports, etc… why not go create it?

JB.


First import? OSM :-D



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

Re: [OSM-talk] A thought on bot edits

[Yves]

@JB, I understood the bot=no tag like the add=no sticker on your physical 
mailbox. 

Yves 

Le 6 octobre 2017 05:37:37 GMT+02:00, JB  a écrit :
>
>Le 05/10/2017 à 22:50, Yuri Astrakhan a écrit :
>> I like the "bot=no" flag, or a more specific one for a given field - 
>
>> "name:en:bot=no" - as long as those flags are not added by a bot :)
>Ho…
>We are now manually contributing one more tag to say it was contributed
>
>manually…
>So many people seem to think one geodatabase can be created only
>through 
>bots, imports, etc… why not go create it?
>JB.
>
>___
>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] A thought on bot edits

[JB]

Le 05/10/2017 à 22:50, Yuri Astrakhan a écrit :
I like the "bot=no" flag, or a more specific one for a given field -  
"name:en:bot=no" - as long as those flags are not added by a bot :)

Ho…
We are now manually contributing one more tag to say it was contributed 
manually…
So many people seem to think one geodatabase can be created only through 
bots, imports, etc… why not go create it?

JB.

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

Re: [Talk-us] Trunk

[Paul Johnson]

On Thu, Oct 5, 2017 at 10:20 PM, Tod Fitch  wrote:

>
> > On Oct 5, 2017, at 8:05 PM, Richie Kennedy 
> wrote:
> > I *strongly* dispute Paul's assertion that a highway that has fully
> > controlled  access but is single carriageway should be "trunk" instead
> > of "motorway." Access control, not number of lanes, should be the
> > primary guidance behind a motorway or trunk classification.
>
> A two lane (one lane each way, probably undivided) limited access (with
> interchanges) is, I believe, called a “super two” and the wiki calls for
> that to be tagged as trunk. [1]
>

Limited access just means few intersections or driveways.  Controlled
access would be interchange exclusive.


> Not sure how long that has been in the wiki, but it has been at least a
> couple of years as I used that guidance in tagging a “super two” in the
> Sierra Nevada foothills several years ago.
>

Correct, I believe a super-2 is a good qualification to be a trunk, not a
motorway.  While they might have a lot of freeway-like features and offer
freeway speeds, few people would typically consider them a freeway.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk

[Tod Fitch]

> On Oct 5, 2017, at 8:05 PM, Richie Kennedy  wrote:
> 
> On Thu, Oct 5, 2017 at 5:30 PM, Martijn van Exel  wrote:
>> 
>> To my mind these are highway=primary mainly because of at-grade 
>> intersections..
>> I am still confused about what makes a trunk road in the US. To my mind it's 
>> roads with
>> no at-grade intersections but not built to interstate standards / not having 
>> an interstate
>> designation... I'm not looking to open up a can of worms but I would really 
>> like to understand.
> 
> If that were the case, then we'd have lots of partially controlled
> access routes (i.e. no driveways, but at-grade intersections) to
> change to "primary." IMHO, routes with partial control of access
> should be classified as "trunk" and any highway with fully controlled
> access (all cross roads are grade separated) should be classified as
> "motorway," including those routes that are not quite to interstate
> standards.
> 
> On Thu, Oct 5, 2017 at 7:48 PM, Paul Johnson  wrote:
> 
>> Alternatively, a single
>> carriageway that is limited access, ie, no intersections, no driveways, only
>> ramps (eg, Chickasaw Turnpike in Oklahoma).  Essentially, almost a motorway
>> but not quite there.
> 
> I *strongly* dispute Paul's assertion that a highway that has fully
> controlled  access but is single carriageway should be "trunk" instead
> of "motorway." Access control, not number of lanes, should be the
> primary guidance behind a motorway or trunk classification.

A two lane (one lane each way, probably undivided) limited access (with 
interchanges) is, I believe, called a “super two” and the wiki calls for that 
to be tagged as trunk. [1]

Not sure how long that has been in the wiki, but it has been at least a couple 
of years as I used that guidance in tagging a “super two” in the Sierra Nevada 
foothills several years ago.


[1] https://wiki.openstreetmap.org/wiki/United_States_roads_tagging#Trunk_tag



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

Re: [Talk-us] Trunk

[Richie Kennedy]

On Thu, Oct 5, 2017 at 5:30 PM, Martijn van Exel  wrote:
>
> To my mind these are highway=primary mainly because of at-grade 
> intersections..
> I am still confused about what makes a trunk road in the US. To my mind it's 
> roads with
> no at-grade intersections but not built to interstate standards / not having 
> an interstate
> designation... I'm not looking to open up a can of worms but I would really 
> like to understand.

If that were the case, then we'd have lots of partially controlled
access routes (i.e. no driveways, but at-grade intersections) to
change to "primary." IMHO, routes with partial control of access
should be classified as "trunk" and any highway with fully controlled
access (all cross roads are grade separated) should be classified as
"motorway," including those routes that are not quite to interstate
standards.

On Thu, Oct 5, 2017 at 7:48 PM, Paul Johnson  wrote:

> Alternatively, a single
> carriageway that is limited access, ie, no intersections, no driveways, only
> ramps (eg, Chickasaw Turnpike in Oklahoma).  Essentially, almost a motorway
> but not quite there.

I *strongly* dispute Paul's assertion that a highway that has fully
controlled  access but is single carriageway should be "trunk" instead
of "motorway." Access control, not number of lanes, should be the
primary guidance behind a motorway or trunk classification.

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

Re: [Talk-us] Trunk

[Paul Johnson]

On Thu, Oct 5, 2017 at 5:30 PM, Martijn van Exel  wrote:
>
> To my mind these are highway=primary mainly because of at-grade
> intersections.. I am still confused about what makes a trunk road in the
> US. To my mind it's roads with no at-grade intersections but not built to
> interstate standards / not having an interstate designation... I'm not
> looking to open up a can of worms but I would really like to understand.
>

A motorway would be two or more carriageways, limited access (ie, no
driveways and no at-grade intersections).

A trunk road would either be a dual carriageway with surface intersections
with cross streets, and limited or no direct driveway access (eg, OK 3 in
Oklahoma County, aka Northwest Expressway).  Alternatively, a single
carriageway that is limited access, ie, no intersections, no driveways,
only ramps (eg, Chickasaw Turnpike in Oklahoma).  Essentially, almost a
motorway but not quite there.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Trunk

[Martijn van Exel]

Question for you all:

What make Michigan state routes 5 and 10[1] trunks rather than primaries?

To my mind these are highway=primary mainly because of at-grade
intersections.. I am still confused about what makes a trunk road in the
US. To my mind it's roads with no at-grade intersections but not built to
interstate standards / not having an interstate designation... I'm not
looking to open up a can of worms but I would really like to understand.

Martijn

[1] https://www.openstreetmap.org/#map=13/42.5188/-83.3982
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-es] Reunión virtual sobre accesibilidad

[Cristina Domínguez]

Buenas!!
Soy Cristina, Geoinquieta en Sevilla
Desde 2014 he utilizado OSM en el ámbito de la accesibilidad en entornos
urbanos en Sevilla.

Me gustaría participar en esa reunión virtual.

Saludos
Cristina Domínguez

-- Forwarded message --
From: Jose Luis Infante 
Date: 2017-10-05 12:39 GMT+02:00
Subject:
To: Discusión en Español de OpenStreetMap 


Hola,

hace ya tiempo que hemos estado hablando por chats y redes sociales
sobre nuestras experiencias en accesibilidad en OSM. Finalmente, a
raíz de estas conversaciones, sería muy conveniente poder organizar
una reunión virtual donde compartir nuestras experiencias: qué hemos
hecho, con quién hemos colaborado, cómo lo hemos organizado, que
dificultades hemos tenido, criterios de accesibilidad que hemos
considerado, etc.

También, obviamente, para debatir sobre el estado del arte y el futuro
del tema de la accesibilidad en OSM. ¿Podemos reflejar la realidad de
las personas con problemas de accesibilidad en OSM? ¿Qué podemos hacer
para que la información sea lo más completa? Y, ¿qué hacemos para
extender nuestra experiencia a otros lugares que todavía no tienen
datos de accesibilidad?

¿Quién se apunta?

Un saludo,

Jose Luis

___
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] A thought on bot edits

[Yuri Astrakhan]

I like the "bot=no" flag, or a more specific one for a given field -
"name:en:bot=no" - as long as those flags are not added by a bot :)

Would it make sense, judging how wikidata* tags have been mostly auto-added
by iD, as well as user's bot efforts, including my own, to treat wikidata
explicitly as a bot tag?  In a way, it is already being treated as such by
many - why not make it official?

On Tue, Oct 3, 2017 at 4:55 AM Christoph Hormann  wrote:

> On Tuesday 03 October 2017, Frederik Ramm wrote:
> > Did your proposal also extend to geoemtries? You said something about
> > bot:* tags, but if a bot were to orthogonalize an existing building,
> > would it then have to create a copy of that tagged
> > "bot:building=yes"? And how could that be differentiated from a
> > building that originally had building=YES and the bot only lowercased
> > the tag value?
>
> My original idea was only about tags but it could be extended to
> geometries of course - as i sketched in my reply to Martin, which would
> essentially mean creating a copy for the building a bot orthogonalizes
> if the building already has a manual building=yes tag.  If the bot only
> changes the tag the building would remain a normal hand mapped geometry
> but would get a bot:building=yes in addition to the building=YES.
>
> Of course duplicating geometry data would make it much more difficult
> for data users to make decisions about selectively using data and it
> would make it much more difficult for editors to allow mappers to edit
> the data correctly.  This is why i originally suggested this only for
> tags - after all the vast majority of bot edits are tag modifications
> only, geometry edits by bots are technically much more complicated to
> do right so they happen less frequently.
>
> As already said - if this approach is not considered favorably it is
> always possible to use the other method and forbid bots to touch
> anything with a bot=no tag and thereby allow mappers to opt out of bot
> edits on a case-by-case basis.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Wochennotiz Nr. 376 26.09.2017–02.10.2017

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 376 mit vielen wichtigen Neuigkeiten aus der 
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2017/10/wochennotiz-nr-376/

Viel Spaß beim Lesen!
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Wochennotiz Nr. 376 26.09.2017–02.10.2017

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 376 mit vielen wichtigen Neuigkeiten aus der 
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2017/10/wochennotiz-nr-376/

Viel Spaß beim Lesen!
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-it] ordine delle way

[Andrea Albani]

>
>
> Ora, visto JOSM mostra benessimo se le geometrie sono state associate in
> ordine o no e perfino che verso hanno le way, da qualche parte questa
> informazione di deve per essere.
>
>
Non ci sono informazioni esplicite di questa natura nel DB, ma si possono
ricavare.

Infatti anche la lista dei nodi è ordinata e quindi il primo nodo della way
stabilisce qual'è il punto di inizio e quindi il verso.

Per quanto riguarda la "capacità" di JOSM nel segnalarti se ci sono delle
way di una relazione non connesse, questo è possibile verificando se
l'ultimo nodo di una way è anche il primo della way successiva nella
relazione.
Nelle relazioni di tipo route ci sono delle eccezioni come nel caso del
poligono chiuso che identifica una rotonda: basta che questo abbia uno dei
suoi nodi in comune con il nodo finale della way posizionata prima nella
relazione (o quello iniziale se la way è successiva nell'ordine) per far si
che JOSM non segnali errori.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Import numeri civici Trento

[Andrea Musuruane]

Ciao,

2017-10-05 18:40 GMT+02:00 Martin Koppenhoefer :

> 2017-10-05 17:37 GMT+02:00 Andrea Musuruane :
>
>> L'etichetta di un determinato numero civico è univoca. Non vedo perché su
>> OSM ci debbano essere più nodi che rappresentano questa informazione.
>>
>
>
> l'alternativa (per avere l'informazione dell'indirizzo di un POI nel db)
> sarebbe di creare una relazione tra civico e POI, mi sembra molto più
> oneroso e complesso da mantenere. Visto che nessuno vuole civici su
> poligoni.
>

L'alternativa è mettere il POI sull'accesso ma proprio non ti piace eh? ;-)
E' anche molto meno oneroso da mappare.


> Se mettiamo più nodi per lo stesso civico, il routing cosa dovrebbe fare?
>> Io vorrei mi portasse dove c'è la targhetta non da un'altra parte.
>>
>
>
> il routing potrebbe portarti ad un ingresso di default, oppure chiederti
> dove vuoi andare. Anche nel'altra ipotesi (civico su un edificio) il
> routing deve decidere se ti porta all'angolo destro o sinistro o al centro
> del'edificio ;-). La distanza tra ingresso e POI comunque è talmente minima
> in quasi tutti i casi che non importa ai fini di routing dove metti il
> civico.
>

Se il router trova più di un civico, io devo sceglierne uno a caso. Quindi
non so dove sto andando.

Anche se poi ci son attività commerciali che usano più spazi adiacenti
>>
>>
>> ed hanno più di un civico.
>>
>>
>>
>> Qui la soluzione mi sembra semplice. I civici si mappano tutti e il POI
>> si mette sull'ingresso principale (o sul building se questi coincidono).
>>
>
>
> anche i POI sul building sono un problema, semanticamente, perché non
> distinguono tra edificio e POI.
>

Io, semanticamente, non vedo problemi. Si accettando controesempi.


>
>
>
>> >> Pertanto come agire? Levare il civico dall'edificio e spostarlo sul
>> >> cancello?
>> >
>> >
>> > Esatto, spostare il civico dal building e metterlo sull'accesso
>> (cancello,
>> > porta, ecc).
>>
>
>
> mi sembra che questo sarebbe redurre le informazioni contenute. Se ho un
> civico che vale per tutto l'edificio, lo posso indicare con il civico
> sull'edificio, e mappando gli ingressi a parte posso anche capire dove
> sono. Invece quando sposti appositamente il civico da un'area su un punto
> perdi un sacco di informazione, rischi di lasciare dei POI all'interno del
> edificio senza indirizzo certo, e non guadagni niente. Perché dovresti
> farlo?
>

>
I dati sorgente contengono i civici su dei nodi. In OSM invece ci sono
>> alcuni building che hanno associati dei civici e, come abbiamo detto, è
>> errato e ovviamente non sappiamo dov'è l'accesso relativo senza un
>> sopralluogo.
>>
>
>
> questa insistenza sul essere "errato" un civico in OSM su un building
> oppure un'area (pertinenze) si basa ancora unicamente su quella regola /
> legge che dice che il numero va esposto all'ingresso?
>

Perdona l'insistenza Martin, però abbiamo deciso tutti insieme tempo fa su
questa ML di adeguarci alle direttive dell'ISTAT per lo stradario e per i
civici.

Le direttive dell'ISTAT, che tutti i comuni italiani DEVONO seguire, dicono
che "il  numero  civico [è] costituito  dal numero  che  contraddistingue
l’accesso esterno che  dall’area  di  circolazione  immette  direttamente
o  indirettamente alle  unità  immobiliari  (abitazioni,  esercizi,
uffici, ecc.)":
https://rnc.istat.it/DOCUMENTI/Manuale_per_le_operazioni_sul_campo.pdf

Il fatto che a volte capiti che un edificio abbia un solo accesso e di
conseguenza un solo numero civico è un caso particolare e non implica
assolutamente nulla.

Spostare il civici dal building all'accesso non perdi informazioni ma ne
guadagni.

Io sarei per eliminare da OSM tutti i civici che sono stati etichettati ai
>> building e utilizzare gli open data per inserire nuovamente i civici (che a
>> questo punto saranno posizionati correttamente sull'accesso). L'operazione
>> non dovrebbe comportare problemi.
>>
>
>
> -1, io sono contrario a degli edit automatici in questo contesto, la
> situazione varia da caso a caso, e sono in ogni caso per la soluzione
> migliore, non per una soluzione unica per tutti i casi.
>

Martin, l'import è un edit automatico. Proprio per questo c'è un processo
di review.

Cancellare informazioni errate (in questo caso il civico sull'edificio,
come prima dimostrato, è sempre errato) e sostituirle con informazioni
corrette (il civico sull'accesso esterno che  dall’area  di  circolazione
immette  direttamente  o  indirettamente alle  unità  immobiliari) non può
essere sbagliato.

Dire che questa operazione è sbagliata significa mettere in discussione la
bontà del dato rilevato sul campo e messo a disposizione dal Comune di
Trento.

Ciao,

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

[Talk-de] FOSSGIS Konferenz 2018 - Call for Papers startet

[Astrid Emde (FOSSGIS e.V.)]

Liebe FOSSGIS-Interessierte,

Die Vorbereitungen für die FOSSGIS-Konferenz 2018 in Bonn laufen. Der 
Call for Papers startet. Die Konferenz findet vom 21. bis 24. März 
statt. Sponsoren und Aussteller sind willkommen. Zeitgleich wird es 
einen internationalen OSGeo Code Sprint geben. Dieser findet im 
bewährten BaseCamp statt.


Die FOSSGIS 2018 findet vom 21. bis 24. März 2018 an der Universität in 
Bonn statt. Zur größten deutschsprachigen Anwenderkonferenz für freie 
Geoinformationssysteme und freie Geodaten, die zum 12. Mal veranstaltet 
wird, erwarten die Organisatoren hunderte Teilnehmer, darunter auch 
einige Experten aus dem Ausland. Veranstalter der Konferenz sind der 
gemeinnützige FOSSGIS e.V. und die OpenStreetMap Community mit 
Unterstützung der Universität Bonn. Das Geographische Institut und das 
Geozentrum dienen als Veranstaltungsorte.


An drei Tagen treffen sich Anwender und Entwickler zum gemeinsamen 
Austausch über Anwendungs- und Arbeitsmöglichkeiten und diskutieren 
neueste Entwicklungen. Die gleichzeitig stattfindende Firmen- und 
Projektausstellung ermöglicht einen direkten Kontakt zu professionellen 
Dienstleistern.
Vor allem der Freitagnachmittag und Samstag stehen im Zeichen der OSM 
Community.


Call for Papers bis 28. November 2017
Der Call for Papers ist eröffnet und läuft bis zum 28. November 2017. 
https://fossgis-konferenz.de/2018/callforpapers/
Forscher, Entwickler und Anwender können einen Vortrag oder Workshop 
einreichen. Entscheidend für die Annahme ist, dass spannende Themen 
behandelt werden, die anregende Diskussionen auslösen. Vorträge zum 
Thema freie Geodaten, wie OpenStreetMap oder Open Data sind ebenso 
möglich wie Beiträge zu Lösungen mit freier Software aus dem Bereich 
WebGIS, Desktop-GIS, Geodatenbanken, Location-Based Services, 
Geoprocessing etc.
Aus der Teilnehmerbefragung 2017 wissen wir um folgende Themenwünsche: 
Docker, Angular2, 1. Schritte in Python, GeoPackage, QGIS für 
Fortgeschrittene, QGIS 3 Plugins, GeoNetwork, GeoServer Einführung, 
GeoTools + Java Topology Suite (JTS), pgRouting, INSPIRE Dienste, 
ATOM-Feeds, Big-Data Geo-Frameworks, Big-Data Analyse in R, SpatiaLite. 
Sehen Sie diese Auflistung als Anregung.
Werden Sie Teil der Konferenz und bewerben Sie sich jetzt mit einem 
Vortrag oder Workshop.
Fragen zum Call for Papers beantworten FOSSGIS-Mitglieder gerne per 
E-Mail an konferenz-o...@fossgis.de.


Die Programmplanung findet beim 9. FOSSGIS Hacking vom 8. bis 10. 
Dezember im Essener Linuxhotel statt, daher wird es keine Verlängerung 
des Call for Papers geben. Das detaillierte Programm wird Anfang Januar 
2018 bekannt gegeben, gleichzeitig wird die Anmeldung eröffnet.


BaseCamp für den internationalen OSGeo Code Sprint
Zeitgleich zur FOSSGIS findet der internationale OSGeo Code Sprint vom 
19. bis 25. März 2017 im Bonner BaseCamp statt. Der In- und Outdoor 
Retro-Park mit ausrangierten Wohnwagen und Zugschlafwagen hat sich mit 
seinem nostalgischen Flair schon bei der FOSS4G 2016 bewährt. „Ein 
idealer Ort für den kreativen Austausch, der von den Teilnehmern 
begeistert angenommen wurde“, so FOSSGIS-Vorstand Till Adams.


Weitere Informationen Weitere Informationen zur FOSSGIS-Konferenz, zum 
Programm, Anreise und Unterkunft, Anmeldung, Helfermöglichkeiten und 
Sponsoren bietet die Konferenzhomepage. 
https://www.fossgis-konferenz.de/2018
Folgen Sie uns auf Twitter sowie auf der FOSSGIS-Talk Mailingliste: 
https://twitter.com/FOSSGIS_Konf 
https://lists.fossgis.de/mailman/listinfo/fossgis-talk-liste


Wir freuen uns über Einreichungen für ein spannendes Programm!

Ihr FOSSGIS-Konferenz-Organisationsteam
--
Astrid Emde

Charter Member
Open Source Geospatial Foundation
http://wiki.osgeo.org/wiki/User:Astrid_Emde



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

[Talk-at] FOSSGIS Konferenz 2018 - Call for Papers startet

[Astrid Emde (FOSSGIS e.V.)]

Liebe FOSSGIS-Interessierte,

Die Vorbereitungen für die FOSSGIS-Konferenz 2018 in Bonn laufen. Der 
Call for Papers startet. Die Konferenz findet vom 21. bis 24. März 
statt. Sponsoren und Aussteller sind willkommen. Zeitgleich wird es 
einen internationalen OSGeo Code Sprint geben. Dieser findet im 
bewährten BaseCamp statt.


Die FOSSGIS 2018 findet vom 21. bis 24. März 2018 an der Universität in 
Bonn statt. Zur größten deutschsprachigen Anwenderkonferenz für freie 
Geoinformationssysteme und freie Geodaten, die zum 12. Mal veranstaltet 
wird, erwarten die Organisatoren hunderte Teilnehmer, darunter auch 
einige Experten aus dem Ausland. Veranstalter der Konferenz sind der 
gemeinnützige FOSSGIS e.V. und die OpenStreetMap Community mit 
Unterstützung der Universität Bonn. Das Geographische Institut und das 
Geozentrum dienen als Veranstaltungsorte.


An drei Tagen treffen sich Anwender und Entwickler zum gemeinsamen 
Austausch über Anwendungs- und Arbeitsmöglichkeiten und diskutieren 
neueste Entwicklungen. Die gleichzeitig stattfindende Firmen- und 
Projektausstellung ermöglicht einen direkten Kontakt zu professionellen 
Dienstleistern.
Vor allem der Freitagnachmittag und Samstag stehen im Zeichen der OSM 
Community.


Call for Papers bis 28. November 2017
Der Call for Papers ist eröffnet und läuft bis zum 28. November 2017. 
https://fossgis-konferenz.de/2018/callforpapers/
Forscher, Entwickler und Anwender können einen Vortrag oder Workshop 
einreichen. Entscheidend für die Annahme ist, dass spannende Themen 
behandelt werden, die anregende Diskussionen auslösen. Vorträge zum 
Thema freie Geodaten, wie OpenStreetMap oder Open Data sind ebenso 
möglich wie Beiträge zu Lösungen mit freier Software aus dem Bereich 
WebGIS, Desktop-GIS, Geodatenbanken, Location-Based Services, 
Geoprocessing etc.
Aus der Teilnehmerbefragung 2017 wissen wir um folgende Themenwünsche: 
Docker, Angular2, 1. Schritte in Python, GeoPackage, QGIS für 
Fortgeschrittene, QGIS 3 Plugins, GeoNetwork, GeoServer Einführung, 
GeoTools + Java Topology Suite (JTS), pgRouting, INSPIRE Dienste, 
ATOM-Feeds, Big-Data Geo-Frameworks, Big-Data Analyse in R, SpatiaLite. 
Sehen Sie diese Auflistung als Anregung.
Werden Sie Teil der Konferenz und bewerben Sie sich jetzt mit einem 
Vortrag oder Workshop.
Fragen zum Call for Papers beantworten FOSSGIS-Mitglieder gerne per 
E-Mail an konferenz-o...@fossgis.de.


Die Programmplanung findet beim 9. FOSSGIS Hacking vom 8. bis 10. 
Dezember im Essener Linuxhotel statt, daher wird es keine Verlängerung 
des Call for Papers geben. Das detaillierte Programm wird Anfang Januar 
2018 bekannt gegeben, gleichzeitig wird die Anmeldung eröffnet.


BaseCamp für den internationalen OSGeo Code Sprint
Zeitgleich zur FOSSGIS findet der internationale OSGeo Code Sprint vom 
19. bis 25. März 2017 im Bonner BaseCamp statt. Der In- und Outdoor 
Retro-Park mit ausrangierten Wohnwagen und Zugschlafwagen hat sich mit 
seinem nostalgischen Flair schon bei der FOSS4G 2016 bewährt. „Ein 
idealer Ort für den kreativen Austausch, der von den Teilnehmern 
begeistert angenommen wurde“, so FOSSGIS-Vorstand Till Adams.


Weitere Informationen Weitere Informationen zur FOSSGIS-Konferenz, zum 
Programm, Anreise und Unterkunft, Anmeldung, Helfermöglichkeiten und 
Sponsoren bietet die Konferenzhomepage. 
https://www.fossgis-konferenz.de/2018


Folgen Sie uns auf Twitter sowie auf der FOSSGIS-Talk Mailingliste:
https://twitter.com/FOSSGIS_Konf
https://lists.fossgis.de/mailman/listinfo/fossgis-talk-liste

Wir freuen uns über Einreichungen für ein spannendes Programm!

Ihr FOSSGIS-Konferenz-Organisationsteam

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

Re: [Talk-it] ordine delle way

[Volker Schmidt]

> Con JOSM puoi cambiare l'ordine, anche in maniera automatica, ma è una
> funzione di JOSM, non dell'API.
>

... e funziona solo se la route è rigorosamente lineare, cioè senza
biforcazioni ed anelli o pezzi a senso unico (cioè sena
role=forward|backward)



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-es] Colaboración con el Ayuntamiento de Figueres

[Esther Mingot]

Buenas tardes a tod@s,

Desde hace un tiempo me estoy reuniendo con uno de los técnicos del 
ayuntamiento de Figueres para tratar diferentes aspectos de OSM. Desde el 
primer momento mostró su interés en poder utilizar OSM como visor de la 
cartografía municipal, léase topografía urbana, inventario de comercios, 
mobiliario urbano, mapas temáticos, etc. El visor que utilizan actualmente no 
es todo lo ágil que sería deseable [1] (aunque ha ido mejorando con el tiempo). 
Como el proyecto/objetivo final es muy amplio, en la última reunión empezamos a 
concretar algunas líneas de actuación:

1- Inventario comercial: en estos momentos están preparando las bases para 
encargar la revisión del inventario comercial, que se realiza cada dos años 
aproximadamente. La idea es incorporar en el pliego la petición de datos 
georreferenciados (UTM) y establecer el tipo de licencia correspondiente que 
nos permita utilizar estos datos en OSM. Tengo pendiente pedirle el listado de 
categorías comerciales que utilizan, para establecer su correspondencia con el 
etiquetado en OSM. Aparte, necesitaría saber qué pasos hay que dar para poder 
realizar la importación directa de estos datos una vez los tengamos 
(documentación a entregar, tipo de licencia, a quién hay que mandarla, cómo, 
etc.) El objetivo será que esta información esté a disposición del ciudadano de 
manera directa, y que éste pueda editarla si es incorrecta o ha quedado 
obsoleta.

2- Accesibilidad: actualmente no disponen de un mapa de accesibilidad de todo 
el municipio, tan solo se han realizado algunos estudios parciales. Este año se 
ha puesto en marcha un gestor de incidencias, con acceso multiplataforma [2]. 
Se hará la propuesta de utilizar la misma infraestructura para crear un 
gestor/aplicación para definir puntos negros de accesibilidad, en el que tanto 
los ciudadanos como los técnicos puedan participar en su detección. Siendo 
conscientes de que algunos no tendrán solución inmediata, hacerlos visibles es 
un primer paso para definir actuaciones futuras. Como aliciente y/o para animar 
a los políticos a que hagan algo, podríamos organizar una mapatón de 
accesibilidad en el municipio. En ese sentido voy a ser toda ojos y oídos a lo 
que estáis haciendo en otras comunidades, espero poder participar en alguna y 
que me echéis una mano cuando vayamos a organizarla aquí.

3- Cartografía: uno de los objetivos principales, y que más reuniones está 
llevando; cargar/incorporar la cartografía municipal (escala 1:500) a OSM. En 
un primer momento le frenó el hecho de que no puedes controlar/validar los 
cambios que realicen otros usuarios. Pero con las herramientas que se están 
empezando a desarrollar en ese sentido, y un servidor propio de tiles, podrían 
monitorizar y controlar estos cambios. Tras descartar por motivos obvios la 
siguiente fase de “borro todo lo que hay y pongo lo mío”, hoy volví a reunirme 
con él para mostrarle como trabaja JOSM (o al menos lo que sé hacer y cómo lo 
hago). Le ha gustado la idea de poder importar datos directamente de un shape, 
y con la opción de modificar geometría tendría resuelto el ajuste de las 
edificaciones sin perder el historial del cambio. Me ha dicho que las dos 
fuentes que estoy usando como base para incorporar edificios y números de 
policía (ICC y catastro) contienen errores, así  que qué mejor fuente que el 
propio Ayuntamiento...

Resumiendo un poco, la idea ahora es conocer el protocolo para que autoricen 
una importación masiva (ya sea primero los negocios y luego la cartografía, al 
revés o todo a la vez) y el tipo de licencia/acuerdo que debería firmar el 
ayuntamiento.

Finalmente, como una muestra más de su interés en el proyecto, hoy se ha 
abierto la puerta a que uno de los próximos programas ocupacionales incluya la 
importación de datos a OSM entre sus objetivos. Su interés está claro, y aunque 
faltaría ver cómo se realiza el mantenimiento posterior de los datos, está 
claro que calles y edificios no suelen moverse, y las afectaciones más usuales 
(cambios de sentido o prioridad de calles) pueden integrarse en sus dinámicas 
de trabajo o avisar a la comunidad de que se han producido… aunque por ahora 
los últimos cambios se han incorporado sin que nadie nos dijera nada ;-)

Espero vuestras opiniones/sugerencias/ideas/debates…
Gracias!

[1] 
http://wgis.figueres.org:8086/mapguide/fusion/templates/mapguide/slate/index.html?ApplicationDefinition=Library://03_LAYOUT/Equip_i_serv.ApplicationDefinition=en
[2] 
http://ca.figueres.cat/la-ciutat/manteniment-urba/comunicacio-d-incidencies-a-l-espai-public-19894/



Sólo la verdad nos hará libres
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] Import numeri civici Trento

[Martin Koppenhoefer]

2017-10-05 17:37 GMT+02:00 Andrea Musuruane :

> L'etichetta di un determinato numero civico è univoca. Non vedo perché su
> OSM ci debbano essere più nodi che rappresentano questa informazione.
>


l'alternativa (per avere l'informazione dell'indirizzo di un POI nel db)
sarebbe di creare una relazione tra civico e POI, mi sembra molto più
oneroso e complesso da mantenere. Visto che nessuno vuole civici su
poligoni.




>
> Se mettiamo più nodi per lo stesso civico, il routing cosa dovrebbe fare?
> Io vorrei mi portasse dove c'è la targhetta non da un'altra parte.
>


il routing potrebbe portarti ad un ingresso di default, oppure chiederti
dove vuoi andare. Anche nel'altra ipotesi (civico su un edificio) il
routing deve decidere se ti porta all'angolo destro o sinistro o al centro
del'edificio ;-). La distanza tra ingresso e POI comunque è talmente minima
in quasi tutti i casi che non importa ai fini di routing dove metti il
civico.




> Anche se poi ci son attività commerciali che usano più spazi adiacenti
>
>
> ed hanno più di un civico.
>
>
>
> Qui la soluzione mi sembra semplice. I civici si mappano tutti e il POI si
> mette sull'ingresso principale (o sul building se questi coincidono).
>


anche i POI sul building sono un problema, semanticamente, perché non
distinguono tra edificio e POI.



> >> Pertanto come agire? Levare il civico dall'edificio e spostarlo sul
> >> cancello?
> >
> >
> > Esatto, spostare il civico dal building e metterlo sull'accesso
> (cancello,
> > porta, ecc).
>


mi sembra che questo sarebbe redurre le informazioni contenute. Se ho un
civico che vale per tutto l'edificio, lo posso indicare con il civico
sull'edificio, e mappando gli ingressi a parte posso anche capire dove
sono. Invece quando sposti appositamente il civico da un'area su un punto
perdi un sacco di informazione, rischi di lasciare dei POI all'interno del
edificio senza indirizzo certo, e non guadagni niente. Perché dovresti
farlo?


I dati sorgente contengono i civici su dei nodi. In OSM invece ci sono
> alcuni building che hanno associati dei civici e, come abbiamo detto, è
> errato e ovviamente non sappiamo dov'è l'accesso relativo senza un
> sopralluogo.
>


questa insistenza sul essere "errato" un civico in OSM su un building
oppure un'area (pertinenze) si basa ancora unicamente su quella regola /
legge che dice che il numero va esposto all'ingresso?


Io sarei per eliminare da OSM tutti i civici che sono stati etichettati ai
> building e utilizzare gli open data per inserire nuovamente i civici (che a
> questo punto saranno posizionati correttamente sull'accesso). L'operazione
> non dovrebbe comportare problemi.
>


-1, io sono contrario a degli edit automatici in questo contesto, la
situazione varia da caso a caso, e sono in ogni caso per la soluzione
migliore, non per una soluzione unica per tutti i casi.

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

Re: [Talk-it] Import numeri civici Trento

[Martin Koppenhoefer]

2017-10-05 17:20 GMT+02:00 Federico Cortese :

> 2017-10-05 17:00 GMT+02:00 Martin Koppenhoefer :
> >
> > lo vedi dal civico dove si entra, in casi più complessi potresti mappare
> il
> > poi come poligono.
> > È anche topologicamente sbagliato che un POI faccia parte del confine di
> un
> > edificio.
> >
>
> Non sono d'accordo. Per una mappatura veloce su strada rilevo quello
> che vedo, quindi mi sembra logico posizionare su un unico POI
> l'entrata, l'indirizzo e l'attività eventualmente svolta all'interno.
>


questo è un altro discorso. Penso anch'io che per pigrizia / efficienza si
può fare in questa maniera, nonostante sbagliata è ancora accettabile.



>
> Se all'interno dello stesso civico esistono più attività diverse,
> allora sono costretto a separare le attività dal civico.
>


si, e a mettere l'indirizzo a tutti i POI, oppure perdi l'informazione.
Anche perché non sai mai se OSM è completo, e quindi da un civico che fa
parte di un ingresso, il quale fa parte di un'edificio, non puoi mai essere
sicuro che valga per tutto l'edificio, nemmeno se guardi tutta la strada,
perché anche se ci sono (mappati) i civici 1, 2, 3 (oppure 1, 3, 5 da un
lato), non potrai mai sapere se non ci mancano 1A, 1B, 1C...



>
> Disegnare il poligono dell'attività rientra in una mappatura molto più
> dettagliata, che può attualmente essere applicata solo in alcuni casi,
> oppure quando l'attività occupa l'intero perimetro dell'edificio, ma
> non può essere considerata la norma.
>


spesso lo potresti fare, ma il lavoro per farlo raramente è giustificato
dal guadagno al quale porta. Non è richiesto una precisione centimetrica,
una stima qualificata sarebbe sufficiente.

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

Re: [Talk-it] ordine delle way

[Martin Koppenhoefer]

2017-10-05 17:40 GMT+02:00 Alfredo Gattai :

> Ciao lista,
>
> qualcuno sa come estrarre dal database di OSM magari usando overpass in
> quale ordine le way sono associate ad una relation?
>
> Il bisogno e' relativamente semplice, per aggiungere ad un catasto
> preesistente in maniera piu' o  meno automatica dovrei passarli degli shape
> che contengano per ogni percorso il "verso" delle varie geometrie, ovvero
> mettere in un campo apposito 1,2,3, etc
>
> Ora, visto JOSM mostra benessimo se le geometrie sono state associate in
> ordine o no e perfino che verso hanno le way, da qualche parte questa
> informazione di deve per essere.
>
> Qualcuno sa dove sta e come estrarla evitandomi cosi' di doverlo rifare a
> mano?
>


le relazioni contengono i membri nell'ordine che le persone le mettono.
Con JOSM puoi cambiare l'ordine, anche in maniera automatica, ma è una
funzione di JOSM, non dell'API.

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

Re: [Talk-br] QUESTÕES SOBRE ESTATÍSTICA DE NÓS OSM NO BRASIL

[Sérgio V .]

Obrigado pelo comentário Marcos.

E desculpem pelo Caps+Lock, tava fazendo em tabela, continuei a escrever e 
colei.


É que tem alguns pontos a considerar:

-o objetivo do levantamento, iniciei pensando assim, é avaliar o mapeamento 
geral no todo, não somente de rede viária;

-e no território todo, não somente áreas urbanas;

Para ver como está a distribuição de mapeamento geral: áreas urbanas, rurais, 
território desocupado, dispersão, etc.

Sem dúvida, mapeamento de vias é importante e básico.


Outro detalhe, mais operacional:

-só do total atual no Brasil deu +/- 62 milhões nós. O que já pesou muito no 
processamento (com 4GB-RAM eu não consegui abrir o pacote  SHP, pra fazer a 
contagem de nós para os polígonos dos 316.574 setores do IBGE; o naoliv 
conseguiu, com 20GB de RAM).  Em função do que já foi pesado de processar, se 
for medir kilometragem em ways  tem que fazer mais alguns processos e 
cruzamentos prévios, o que pesa ainda mais, acredito: selecionar vias; 
selecionar em meio urbano; medir o comprimento.


Ao computar Nós/População , dá o significado de nós por pessoa.

Se computar Nós/Área(km2), dá outro significado: pode ter área de mato super 
bem mapeada, mas nenhuma pessoa lá.


Com nós fica viável de computar e me parece dá um panorama geral bom.

Indica a densidade de mapeamento, isto é, cada nó é um click de um usuário no 
mouse.

Tem o site do tyrasd, só baseado em densidade de nós:

https://tyrasd.github.io/osm-node-density/#4/-16.34/-50.54/latest,places


Os nós são o elemento fundamental de todo objeto OSM: a) nó solto; b) way 
aberto; c) way fechado; d) relação entre estes.


Também varia, se pode escolher o tipo de representação melhor para avaliar cada 
caso:

-no meio urbano: onde mais falta; onde já tem bastante e se poderia sugerir 
mapear outros lugares onde falta;

-no meio rural: idem;

-as tendências no Brasil em geral: mais mapeamento urbano, ou mais rural, 
linhas de tendência para dentro do território; etc.


À medida que eu tiver tempo vou colocar na wiki uns mapas de resultados de 
densidade de nós no Brasil (DNHab e DNKm2), pra gente ir vendo qual o mais 
representativo. Densidade populacional pura do IBGE já coloquei lá. Pretendo 
conseguir fazer alguns mapas estatísticos de nós, tipo evidenciar acima e 
abaixo do desvio padrão, etc. Tou subindo para um dropbox o SHP básico da 
contagem atual de nós-OSM em 316.574 setores-IBGE, se alguém mais tiver 
interesse em mexer nisso também, pra baixar.


O objetivo é ter uma visão geral do estado do mapeamento, e eventuais 
conclusões e propostas a nível de sugestão. O mais importante penso é apenas 
ver onde mais falta. Nunca se vai propor remover dados onde eventualmente 
esteja super mapeado. Cada um é livre pra mapear onde e o que quiser, mesmo que 
já esteja super mapeado.


Valeu, vamos pensando.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs



De: Marcos Fedato 
Enviado: quarta-feira, 4 de outubro de 2017 18:21
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] QUESTÕES SOBRE ESTATÍSTICA DE NÓS OSM NO BRASIL

Eu sempre pensei em calcular extensao de ruas nas areas urbanas.

Nós variam em quantidade dependendo se alguem fez a curva mais ou menos 
detalhada vai ter mais pontos.

Eu cruzaria as manchas urbanas e as ruas e veria a densidade de m de rua por m 
quadrado de area urbana.

Daria para saber qual cidade tem mais e menos arruamento por espaço urbano e 
ver as com os menores índices nelas deve faltar ruas (será?).

Atenciosamente,
Marcos Fedato



Enviado do meu smartphone Samsung Galaxy.


 Mensagem original 
De: "Sérgio V." 
Data: 04/10/17 18:09 (GMT-03:00)
Para: talk-br@openstreetmap.org
Assunto: [Talk-br] QUESTÕES SOBRE ESTATÍSTICA DE NÓS OSM NO BRASIL


Pessoal, pergunta:

QUESTÕES SOBRE ESTATÍSTICA DE NÓS OSM NO BRASIL:

Créditos à grande ajuda do naoliv extraindo e contabilizando nós por setores, e 
dicas, ideias e tentativas de vários da comunidade e do grupo QGIS.

--
EXAMES DE QUANTIDADE DE NÓS OSM (NOS SETORES CENSITÁRIOS):

Sendo:
DNH = Densidade de Nós-OSM / Habitante
DNK = Densidade de Nós-OSM / Km2
DP  = Densidade Populacional (Demográfica: Hab. / Km2)
LOCAL CD = CD_GEOCODI (setor cf. IBGE)

AMOSTRAS DE VALORES MÁXIMOS E MÍNIMOS:
(Sendo: VALORES MAIS BAIXOS DIFERENTES DE ZERO)
--
DNH MÍN.:   0.00049628 / DNK=8.12799313 / DP= 16377.90616394  / LOCAL 
CD: 230550605000146 / URBANO: Bastiana
DNH MÁX.:   22935. / DNK=   13.47933983 / DP= 0.00058772  / LOCAL 
CD: 51065050525 / RURAL

DNK MÍN.:   0.00079655 / DNH=0.02061856 / DP= 0.03863270  / LOCAL 
CD: 13027020546 / RURAL
DNK MÁX.:   

[Talk-it] ordine delle way

[Alfredo Gattai]

Ciao lista,

qualcuno sa come estrarre dal database di OSM magari usando overpass in
quale ordine le way sono associate ad una relation?

Il bisogno e' relativamente semplice, per aggiungere ad un catasto
preesistente in maniera piu' o  meno automatica dovrei passarli degli shape
che contengano per ogni percorso il "verso" delle varie geometrie, ovvero
mettere in un campo apposito 1,2,3, etc

Ora, visto JOSM mostra benessimo se le geometrie sono state associate in
ordine o no e perfino che verso hanno le way, da qualche parte questa
informazione di deve per essere.

Qualcuno sa dove sta e come estrarla evitandomi cosi' di doverlo rifare a
mano?

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

Re: [Talk-it] Import numeri civici Trento

[Andrea Musuruane]

Ciao,

2017-10-05 15:57 GMT+02:00 Maurizio Napolitano :

> >> Della serie:
> >> un utente ha inserito il civico visto sulla casa
> >> un altro utente ha inserito un negozio ed ha assegnato il civico al POI.
> >> Qui come ci si comporta?
> >
> >
> > In generale il civico è associato all'accesso. Se il POI non ha un civico
> > specifico per il suo ingresso, IMHO questo non dovrebbe avere i tag
> addr:*.
>
> Una questioen che però non va sottovalutata sono i preset che, strumenti
> come
> IDEditor offrono.
> In IDEditor, quando si inserisce un POI, viene presentata anche la maschera
> con l'indirizzo completo da inserire.
> Lo stesso vale per Wheelmaps ed altri ancora.
>

Se i preset sono errati, io sarei per cambiare i preset, non per cambiare
OSM...

Comunque in questo caso non trovo i preset errati, trovo errato che siano
obbligatori.

L'etichetta di un determinato numero civico è univoca. Non vedo perché su
OSM ci debbano essere più nodi che rappresentano questa informazione.

Se mettiamo più nodi per lo stesso civico, il routing cosa dovrebbe fare?
Io vorrei mi portasse dove c'è la targhetta non da un'altra parte.

> [...]
> > Personalmente se POI e civico coincidono nell'accesso li metto sempre
> > insieme. Sono geograficamente nello stesso punto.
> >
> > Se un utente cancella tutte le informazioni dal nodo è errato.
>
> È errato ma viene fatto.
>

Vengono fatte anche tante altre cose errate. Non per questo credo che
dobbiamo uniformarci verso il basso.


> Anche se poi ci son attività commerciali che usano più spazi adiacenti
> ed hanno più di un civico.
>

Qui la soluzione mi sembra semplice. I civici si mappano tutti e il POI si
mette sull'ingresso principale (o sul building se questi coincidono).


> >> Rimane poi la questione dell'edificio su più vie dove, un lato è più
> >> vicino ad una strada,
> >> ma l'ingresso principale è più vicino a quella ufficiale ma, per via
> >> di percorsi privati appare
> >> separato dalla via.
> >> È vero che si possono disegnare i percorsi privati.
> >> In tal caso bisogna assegnare anche il nome della via al vialetto
> privato?
> >
> >
> > Direi di no.
>
> Tra l'altro mi sono accorto che ho scritto la frase sbagliata: ho
> dimenticato un "NON".
> Intendevo dire che capita che l'edificio sia più vicino ad una strada
> ma l'ingresso ufficiale,
> per via di percorsi privato ed altro, appare più lontano dalla strada
> da cui l'edificio eredita
> il civico.
>
> >> Pertanto come agire? Levare il civico dall'edificio e spostarlo sul
> >> cancello?
> >
> >
> > Esatto, spostare il civico dal building e metterlo sull'accesso
> (cancello,
> > porta, ecc).
>
> quindi proponi una operazione manuale.
> Considera che ci sono anche zone dove mancano gli edifici.
> Se l'import diventa manuale, dal mio punto di vista, non è
> propriamente un import
> ma una verifica basata sul confronto manuale fra basi dati diverse.
>

Personalmente sono per una soluzione molto più semplice e realizzabile con
l'import proposto.

I dati sorgente contengono i civici su dei nodi. In OSM invece ci sono
alcuni building che hanno associati dei civici e, come abbiamo detto, è
errato e ovviamente non sappiamo dov'è l'accesso relativo senza un
sopralluogo.

Io sarei per eliminare da OSM tutti i civici che sono stati etichettati ai
building e utilizzare gli open data per inserire nuovamente i civici (che a
questo punto saranno posizionati correttamente sull'accesso). L'operazione
non dovrebbe comportare problemi.

Ciao,

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

Re: [Talk-it] Import numeri civici Trento

[Andrea Musuruane]

2017-10-05 17:20 GMT+02:00 Federico Cortese :

> 2017-10-05 17:00 GMT+02:00 Martin Koppenhoefer :
> >
> > lo vedi dal civico dove si entra, in casi più complessi potresti mappare
> il
> > poi come poligono.
> > È anche topologicamente sbagliato che un POI faccia parte del confine di
> un
> > edificio.
> >
>
> Non sono d'accordo. Per una mappatura veloce su strada rilevo quello
> che vedo, quindi mi sembra logico posizionare su un unico POI
> l'entrata, l'indirizzo e l'attività eventualmente svolta all'interno.
>
> Se all'interno dello stesso civico esistono più attività diverse,
> allora sono costretto a separare le attività dal civico.
>
> Disegnare il poligono dell'attività rientra in una mappatura molto più
> dettagliata, che può attualmente essere applicata solo in alcuni casi,
> oppure quando l'attività occupa l'intero perimetro dell'edificio, ma
> non può essere considerata la norma.
>

+1

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

Re: [Talk-it] Import numeri civici Trento

[Federico Cortese]

2017-10-05 17:00 GMT+02:00 Martin Koppenhoefer :
>
> lo vedi dal civico dove si entra, in casi più complessi potresti mappare il
> poi come poligono.
> È anche topologicamente sbagliato che un POI faccia parte del confine di un
> edificio.
>

Non sono d'accordo. Per una mappatura veloce su strada rilevo quello
che vedo, quindi mi sembra logico posizionare su un unico POI
l'entrata, l'indirizzo e l'attività eventualmente svolta all'interno.

Se all'interno dello stesso civico esistono più attività diverse,
allora sono costretto a separare le attività dal civico.

Disegnare il poligono dell'attività rientra in una mappatura molto più
dettagliata, che può attualmente essere applicata solo in alcuni casi,
oppure quando l'attività occupa l'intero perimetro dell'edificio, ma
non può essere considerata la norma.

Ciao,
Federico

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

Re: [Talk-it] Import numeri civici Trento

[Martin Koppenhoefer]

sent from a phone

On 5. Oct 2017, at 16:25, Andrea Musuruane  wrote:

>> non si mette sullo stesso nodo dell'ingresso, per esempio. 
>> 
>> Perché? Non devo sapere da dove entrare?
> 
> Perché? Non devo sapere da dove entrare?


lo vedi dal civico dove si entra, in casi più complessi potresti mappare il poi 
come poligono.
È anche topologicamente sbagliato che un POI faccia parte del confine di un 
edificio.



> 
> Inoltre, mi sembra di cogliere un controsenso. Se per te addr:* va su 
> entrance e addr:* va sul POI, coma fa entrance a non andare sul POI?


non capisco il controsenso. addr:* è una proprietà, sia dell’ingresso che del 
POI.


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

Re: [Talk-it] Import numeri civici Trento

[Andrea Musuruane]

2017-10-05 16:07 GMT+02:00 Martin Koppenhoefer :

>
>
> 2017-10-05 15:01 GMT+02:00 Andrea Musuruane :
>
>>
>>> era un esempio. Se concordi che entrance=* è un feature e non una
>>> proprietà dovrebbe essere naturale non mischiarlo con altri features
>>> (regola di pricipio).
>>>
>>
>> In Italia i civici sono associati agli accessi. Se non si possono mettere
>> sul tag entrance (The entrance=* key describes the point where you can go
>> into a building or enclosed area), allora dove dovremmo metterli?
>>
>
>
> nonono, non ci capiamo. ;-)
> Certo che i civici vanno sul entrance. Non vanno mischiati i POI con gli
> entrance. Un ristorante o un negozio non si mette sullo stesso nodo
> dell'ingresso, per esempio.
>

Perché? Non devo sapere da dove entrare?

Inoltre, mi sembra di cogliere un controsenso. Se per te addr:* va su
entrance e addr:* va sul POI, coma fa entrance a non andare sul POI?

Ciao,

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

Re: [OSM-ja] 10/14 東京！街歩き！マッピングパーティ：第12回 旧古河庭園

[yasunari yamashita]

山下です。皆さんこんにちわ。

東京を街歩きして、
楽しみながら 自由な地図であるOpenStreetMapに書いていくマッピングパーティ、
第12回は旧古河庭園は、来週末の開催です。
https://openstreetmap.connpass.com/event/66624/
みなさん、どうぞお越しください！！

2017年9月12日 13:09 yasunari yamashita :

> 山下です。皆さんこんにちわ。
> こちらは歩く方のマッピングパーティのご案内です。
>
> 東京！街歩き！マッピングパーティ：第12回 旧古河庭園
> https://openstreetmap.connpass.com/event/66624/
> 10/14 (土)に開催します。
>
> 皆さん、どうぞご参加ください！！
> --
> 山下康成＠東京都新宿区
>



-- 
山下康成＠東京都新宿区
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-it] Import numeri civici Trento

[Martin Koppenhoefer]

2017-10-05 15:01 GMT+02:00 Andrea Musuruane :

>
>> era un esempio. Se concordi che entrance=* è un feature e non una
>> proprietà dovrebbe essere naturale non mischiarlo con altri features
>> (regola di pricipio).
>>
>
> In Italia i civici sono associati agli accessi. Se non si possono mettere
> sul tag entrance (The entrance=* key describes the point where you can go
> into a building or enclosed area), allora dove dovremmo metterli?
>


nonono, non ci capiamo. ;-)
Certo che i civici vanno sul entrance. Non vanno mischiati i POI con gli
entrance. Un ristorante o un negozio non si mette sullo stesso nodo
dell'ingresso, per esempio.

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

Re: [Talk-it] Import numeri civici Trento

[Martin Koppenhoefer]

2017-10-05 14:59 GMT+02:00 Andrea Musuruane :

> Il name però non è del parking_aisle ma della piazza
>
>

perché? Penso tutte le strade su una piazza che non hanno esplicitamente un
nome diverso hanno il nome della piazza. Come anche tutti i marciapiedi e
tutte le ciclabili che non hanno un nome diverso hanno il nome della strada.

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

Re: [Talk-it] Import numeri civici Trento

[Maurizio Napolitano]

>> In realtà abbiamo riscontrato degli errori.
>> Si tratta di alcune banalità come i nomi delle vie non espansi (es. Via G.
>> Mazzini) o scritti in maiuscolo/minuscolo (es. "via" vs "Via") o male
>> interpretati
>> (es. Piazza di Fiera vs Piazza Fiera) o con errori di battitura.
>
>
> Questo è assolutamente normale :-) La fase di QA serve anche per eliminare
> questi errori (e avere una certa coerenza nella mappa).

Certo ma la QA serve a prescindere dall'import :)

>> Di fatto tutti quelli che, quanto esposto sopra, sono stati ignorati
>> per rispetto del lavoro
>> fatto dalla comunità.
>
>
> Ho il massimo rispetto per il lavoro che tutti facciamo quotidianamente su
> OSM, il problema è che spesso ci dimentichiamo di essere una comunità.

il problema è nella definizione del termine comunità.
In ogni caso non voglio aprire una discussione filosofica in merito :)
Hai comunque ragione: era meglio se scrivevo "rispettare il lavoro
fatto dagli altri"

>> Della serie:
>> un utente ha inserito il civico visto sulla casa
>> un altro utente ha inserito un negozio ed ha assegnato il civico al POI.
>> Qui come ci si comporta?
>
>
> In generale il civico è associato all'accesso. Se il POI non ha un civico
> specifico per il suo ingresso, IMHO questo non dovrebbe avere i tag addr:*.

Una questioen che però non va sottovalutata sono i preset che, strumenti come
IDEditor offrono.
In IDEditor, quando si inserisce un POI, viene presentata anche la maschera
con l'indirizzo completo da inserire.
Lo stesso vale per Wheelmaps ed altri ancora.

> [...]
> Personalmente se POI e civico coincidono nell'accesso li metto sempre
> insieme. Sono geograficamente nello stesso punto.
>
> Se un utente cancella tutte le informazioni dal nodo è errato.

È errato ma viene fatto.
Anche se poi ci son attività commerciali che usano più spazi adiacenti
ed hanno più di un civico.

>> Rimane poi la questione dell'edificio su più vie dove, un lato è più
>> vicino ad una strada,
>> ma l'ingresso principale è più vicino a quella ufficiale ma, per via
>> di percorsi privati appare
>> separato dalla via.
>> È vero che si possono disegnare i percorsi privati.
>> In tal caso bisogna assegnare anche il nome della via al vialetto privato?
>
>
> Direi di no.

Tra l'altro mi sono accorto che ho scritto la frase sbagliata: ho
dimenticato un "NON".
Intendevo dire che capita che l'edificio sia più vicino ad una strada
ma l'ingresso ufficiale,
per via di percorsi privato ed altro, appare più lontano dalla strada
da cui l'edificio eredita
il civico.

>> Pertanto come agire? Levare il civico dall'edificio e spostarlo sul
>> cancello?
>
>
> Esatto, spostare il civico dal building e metterlo sull'accesso (cancello,
> porta, ecc).

quindi proponi una operazione manuale.
Considera che ci sono anche zone dove mancano gli edifici.
Se l'import diventa manuale, dal mio punto di vista, non è
propriamente un import
ma una verifica basata sul confronto manuale fra basi dati diverse.

>
>> http://tools.geofabrik.de/osmi/?view=addresses=11.12688=46.07124=18=street_not_found
>> Il tool dichiara che i civici sono associati ad una via non presente,
>> in realtà la via è presente: si tratta di una piazza.
>> Il problema è che la piazza è taggata come parcheggio.
>
>
> Personalmente mi sembra che sia mappato tutto correttamente. Non sempre
> esiste una highway a cui si può dare il nome della piazza e che passa
> attraverso questa.

In realtà qui esiste una highway e posso aggiungere il nome.
Negli altri mi diventa più dura.

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

Re: [Talk-it] Import numeri civici Trento

[Federico Cortese]

2017-10-05 15:01 GMT+02:00 Andrea Musuruane :
>
> In Italia i civici sono associati agli accessi. Se non si possono mettere
> sul tag entrance (The entrance=* key describes the point where you can go
> into a building or enclosed area), allora dove dovremmo metterli?
>

+1 anche io ho sempre mappato il civico sul nodo con entrance=*, non
vedo cosa ci sia di sbagliato.

Per i POI mi pare che sia ridondante duplicare l'indirizzo su su due
nodi separati per POI e civico: secondo me si può usare un nodo unico
in corrispondenza dell'ingresso, a meno di casi particolari.

Ciao,
Federico

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

Re: [Talk-it] Import numeri civici Trento

[Andrea Musuruane]

Ciao Martin,

2017-10-05 12:12 GMT+02:00 Martin Koppenhoefer :

>
>
> sent from a phone
>
> > On 5. Oct 2017, at 10:13, Andrea Musuruane  wrote:
> >
> > Tra l'altro ho delle difficoltà a trovare un esempio dove ci sia il nome
> di un accesso. Puoi aiutarmi?
>
>
> era un esempio. Se concordi che entrance=* è un feature e non una
> proprietà dovrebbe essere naturale non mischiarlo con altri features
> (regola di pricipio).
>

In Italia i civici sono associati agli accessi. Se non si possono mettere
sul tag entrance (The entrance=* key describes the point where you can go
into a building or enclosed area), allora dove dovremmo metterli?

Ciao,

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

Re: [Talk-it] Import numeri civici Trento

[Andrea Musuruane]

Ciao,

2017-10-05 12:15 GMT+02:00 Martin Koppenhoefer :

>
>
> sent from a phone
>
> > On 5. Oct 2017, at 10:13, Andrea Musuruane  wrote:
> >
> > Le highway ci sono ma sono highway=service + service=parking_aisle. Non
> mi sembra corretto mettere il nome della piazza su di queste.
>
>
> non vedo problemi. Il parking_aisle lo metto solo ai percorsi secondarie
> dei parcheggi, ma anche se non ci sono altre vie, il nome mi sembra
> comunque non sbagliato. Spesso ci sono anche percorsi pedonali alle piazze.
>

Il name però non è del parking_aisle ma della piazza

Ciao,

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

[Talk-se] Samiska namn

[Ture Pålsson]

Taggen name:se (nordsamiska) är lätt att förväxla med name:sv (svenska).
Det misstänker jag har hänt med de här objekten (eller, ja "sjuksköterska"
och "runsten" är ju knappast namn alls):

   nodeid   |   wayid   | relationid |  name  |   se
+---++--
--+-
|  25444527 || Ericsson house 05  | Ericsson
Hus 05
|  25444613 || Ericsson house 04  | Ericsson
Hus 04
|  27445176 || Karbosjön  | Karbosjön
| 132081062 || Världskulturmuseet |
Världskulturmuseet
| 308248649 || Søndre Hogsjø  | Hosjö
| 504242796 || Gladhammarsgruvor  |
Gladhammarsgruvor
|  34573224 ||| Eckerö
linjen Hamn
   27559814 |   || Luleå  | Luleå
   80268995 |   || Nynäshamn  | Nynäshamn
  302269885 |   || Gotlands kommun| Gotlands
kommun
  459473619 |   || Medic  |
Sjuksköterska
  821049415 |   || Brudesløret| Brudslöjan
 2435571606 |   || Little Pothole | Lillgrytan
 2995633503 |   || runsten| Runsten

Sedan finns det några saker med name:se som jag tycker ser skumma ut -- är
inte -järvi finska och -jaure en föråldrad "försvenskad" stavning? Borde
dessa korrigeras?

|   |2921619 | Ripaisenjärvi  |
Ripaisenjaure
|  28945801 || Luossajärvi| Luossajaure
|   |7295458 | Abiskojaure| Abiskojärvi
|   |1554525 | Rautasjärvi| Rautasjaure
|   |2171925 | Vuoskojärvi| Vuoskojaure

Jag har själv ingen koll alls på samiska annat än att jag vet ungefär hur
det brukar se ut, så jag tänker inte börja fixa saker själv, för då ställer
jag säkert till med något dumt... Troligen ligger en del av objekten i
listorna ovan i Finland eller Norge; den enda geografiska avgränsningen jag
gjort är att de finns med i geofabrik-utdraget för Sverige.
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-GB] Talk-GB Digest, Vol 133, Issue 8

[Nils Nolde]

Ok, I don´t have a particular opinion on this. If this is the consensus,
we´ll go with that.

Thanks everyone for contributing!

On Thu, Oct 5, 2017 at 2:00 PM,  wrote:

> Send Talk-GB mailing list submissions to
> talk-gb@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/talk-gb
> or, via email, send a message with subject or body 'help' to
> talk-gb-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-gb-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-GB digest..."
>
>
> Today's Topics:
>
>1. Re: Red route attribution (Paul Berry)
>
>
> --
>
> Message: 1
> Date: Wed, 4 Oct 2017 13:58:02 +0100
> From: Paul Berry 
> To: Philip Barnes 
> Cc: Talk GB 
> Subject: Re: [Talk-GB] Red route attribution
> Message-ID:
>  caxsr...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Phil wrote:
>
> > As far as I am aware red routes only exist in that there London, so a UK
> wide practice is unlikely.
>
> > Probably equivalent to no stopping tagging combined with opening hours?
>
> I'd go with this. While Red Routes are London and West Midlands only,
> no_stopping and opening_hours tags would cover both those and the
> better-known Clearways (though note the rarer *Urban Clearways* allow you
> to quickly pick up or set down passengers, so they are not no_stopping
> routes).
>
> Regards,
> *Paul*
>
> On 4 October 2017 at 11:16, Philip Barnes  wrote:
>
> > As far as I am aware red routes only exist in that there London, so a UK
> > wide practice is unlikely.
> >
> > Probably equivalent to no stopping tagging combined with opening hours?
> >
> > Phil (trigpoint)
> >
> > On 4 October 2017 10:14:33 BST, Nils Nolde  wrote:
> >>
> >> Hi all,
> >>
> >> I´m trying to find out if there´s a common practice across the UK to
> >> attribute red routes?
> >>
> >> I found a few examples on how people deal with them, but no best
> >> practice. It seems most common to put 'red_route' for tag
> >> 'restriction_designation':
> >> http://taginfo.openstreetmap.org.uk/search?q=red_route#values
> >>
> >> Would it make sense to add 2 values to the 'restriction' tag:
> >> 'red_route_single', 'red_route_double'? Or a 'red_route' tag? Not sure
> >> about OSM policies here.. But I´m sure one could get the info at least
> for
> >> London from Transport for London.
> >>
> >> Many thanks
> >> Nils
> >>
> >
> > --
> > Sent from my Android device with K-9 Mail. Please excuse my brevity.
> >
> > ___
> > Talk-GB mailing list
> > Talk-GB@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb
> >
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL:  attachments/20171004/bc520ef4/attachment-0001.html>
>
> --
>
> Subject: Digest Footer
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> --
>
> End of Talk-GB Digest, Vol 133, Issue 8
> ***
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-es] Reunión virtual sobre accesibilidad

[Miguel Sevilla-Callejo]

Hola José Luis,

Gracias por tomar la iniciativa y hacer un llamamiento a las personas que
estamos trabajando en este tema.

Yo, personalmente me apunto, y creo que, por lo que nos toca, estaremos el
resto de coordinadores del grupo de Mapeado Colaborativo de Zaragoza[1]

Ya iremos cerrando la cita.

Un saludo

[1] http://mapcolabora.org

--
 Miguel Sevilla-Callejo
from my mobile 

El 5/10/2017 12:41, "Jose Luis Infante"  escribió:

> Hola,
>
> hace ya tiempo que hemos estado hablando por chats y redes sociales sobre
> nuestras experiencias en accesibilidad en OSM. Finalmente, a raíz de estas
> conversaciones, sería muy conveniente poder organizar una reunión virtual
> donde compartir nuestras experiencias: qué hemos hecho, con quién hemos
> colaborado, cómo lo hemos organizado, que dificultades hemos tenido,
> criterios de accesibilidad que hemos considerado, etc.
>
> También, obviamente, para debatir sobre el estado del arte y el futuro del
> tema de la accesibilidad en OSM. ¿Podemos reflejar la realidad de las
> personas con problemas de accesibilidad en OSM? ¿Qué podemos hacer para que
> la información sea lo más completa? Y, ¿qué hacemos para extender nuestra
> experiencia a otros lugares que todavía no tienen datos de accesibilidad?
>
> ¿Quién se apunta?
>
> Un saludo,
>
> Jose Luis
>
> ___
> 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

[Talk-es] Reunión virtual sobre accesibilidad

[Jose Luis Infante]

Hola,

hace ya tiempo que hemos estado hablando por chats y redes sociales sobre
nuestras experiencias en accesibilidad en OSM. Finalmente, a raíz de estas
conversaciones, sería muy conveniente poder organizar una reunión virtual
donde compartir nuestras experiencias: qué hemos hecho, con quién hemos
colaborado, cómo lo hemos organizado, que dificultades hemos tenido,
criterios de accesibilidad que hemos considerado, etc.

También, obviamente, para debatir sobre el estado del arte y el futuro del
tema de la accesibilidad en OSM. ¿Podemos reflejar la realidad de las
personas con problemas de accesibilidad en OSM? ¿Qué podemos hacer para que
la información sea lo más completa? Y, ¿qué hacemos para extender nuestra
experiencia a otros lugares que todavía no tienen datos de accesibilidad?

¿Quién se apunta?

Un saludo,

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

Re: [Talk-it] Import numeri civici Trento

[Martin Koppenhoefer]

sent from a phone

> On 5. Oct 2017, at 10:13, Andrea Musuruane  wrote:
> 
> Le highway ci sono ma sono highway=service + service=parking_aisle. Non mi 
> sembra corretto mettere il nome della piazza su di queste.


non vedo problemi. Il parking_aisle lo metto solo ai percorsi secondarie dei 
parcheggi, ma anche se non ci sono altre vie, il nome mi sembra comunque non 
sbagliato. Spesso ci sono anche percorsi pedonali alle piazze.

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

Re: [Talk-it] Import numeri civici Trento

[Martin Koppenhoefer]

sent from a phone

> On 5. Oct 2017, at 10:13, Andrea Musuruane  wrote:
> 
> Tra l'altro ho delle difficoltà a trovare un esempio dove ci sia il nome di 
> un accesso. Puoi aiutarmi?


era un esempio. Se concordi che entrance=* è un feature e non una proprietà 
dovrebbe essere naturale non mischiarlo con altri features (regola di pricipio).

Comunque ci sono gli ingressi con nomi o ref, in genere occorre con posti 
grandi come stazioni ferroviarie, zoo, fabbriche, ospedali, centri commerciali, 
ecc.

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

Re: [Talk-it] Import numeri civici Trento

[Martin Koppenhoefer]

sent from a phone

> On 5. Oct 2017, at 10:13, Andrea Musuruane  wrote:
> 
> Tra l'altro inserire i tag addr:* su due punti significherebbe che ci sono 
> due targhette uguali su due accessi diversi, che è una cosa che nella realtà 
> non dovrebbe accadere (secondo le norme ISTAT).


se ho capito bene la situazione a Trento è proprio la situazione lì di avere lo 
stesso civico su più indirizzi.

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

Re: [Talk-it] Import numeri civici Trento

[Martin Koppenhoefer]

sent from a phone

> On 5. Oct 2017, at 10:13, Andrea Musuruane  wrote:
> 
> Se capisco bene, qui dici di inserire il civico sul POI solo è questo ha 
> effettivamente associato il civico (ovvero nella maggior parte dei casi è 
> presente la targhetta del civico).


non, io direi di inserire il civico all’ingresso e aggiungere l’indirizzo anche 
a tutti i POI come proprietà del POI.

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

Re: [OSM-talk-fr] UMap planté (HOT)

[Jocelyn Jaubert]

Bonjour,

Merci d'avoir reporté le problème.

Yohan a pu résoudre le souci, et umap remarche maintenante.

-- 
Jocelyn


On Thu, Oct 05, 2017 at 04:19:26AM +0200, Philippe Verdy wrote:
> signalé sur
> https://hotosm.slack.com/messages/C042TUWCV/convo/C4MMB6PD4-1507161772.85/
> 
> UMap semble planté pour la mise à jour des cartes de projets HOT.
> 
> Je vais aussi signaler sur le GitHub
> https://github.com/umap-project/umap/issues/new

> ___
> 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-be] How we deal with this kind of note

[Glenn Plas]

On 05-10-17 11:10, Marc Gemis wrote:
> Does a tourist information sign indicates any access rights ? Is the
> fact that a place is for rent indicates any access rights to the
> driveway ?  It can still be access=customers (or visitors, but we
> don't have that)

What I am sure about is that when you don't want tourists on your
property, you do not put up a tourist sign showing people where to go.
It's like an invitation to trespass your property.

reasonable doubt is definitely a thing

> 
> m.
> 
> On Thu, Oct 5, 2017 at 10:58 AM, joost schouppe
>  wrote:
>> Jakka mapped it as private, based on an anonymous note. However, we now have
>> clear indications this is wrong. We can't use Streetview to define this as
>> access=yes, but I believe we can use this to overrule an anonymous source.
>> So I have removed the tag and left a fixme and a comment at the note. I
>> would suggest we only change this based on a survey or a decent reply from
>> the local government.
>>
>> ___
>> 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
> 


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

Re: [OSM-talk-be] How we deal with this kind of note

[joost schouppe]

I'm not saying it does. I'm saying that if there's reasonable doubt, we
shouldn't map anonymous info without a local survey or some other proof.

2017-10-05 11:10 GMT+02:00 Marc Gemis :

> Does a tourist information sign indicates any access rights ? Is the
> fact that a place is for rent indicates any access rights to the
> driveway ?  It can still be access=customers (or visitors, but we
> don't have that).
>
> m.
>
> On Thu, Oct 5, 2017 at 10:58 AM, joost schouppe
>  wrote:
> > Jakka mapped it as private, based on an anonymous note. However, we now
> have
> > clear indications this is wrong. We can't use Streetview to define this
> as
> > access=yes, but I believe we can use this to overrule an anonymous
> source.
> > So I have removed the tag and left a fixme and a comment at the note. I
> > would suggest we only change this based on a survey or a decent reply
> from
> > the local government.
> >
> > ___
> > 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
>



-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [OSM-talk] All the subway systems in the world

[alan_gr]

Ilya Zverev-2 wrote
> Hi again,
> Now it has all the systems for Europe

Hi,
I'm not clear how it is decided which systems are included and which aren't.
In Spain, why is Bilbao in while Valencia, Seville, Malaga are out? I can't
see a difference in how the last three are tagged in OSM compared to Bilbao.





--
Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html

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

Re: [OSM-talk-be] How we deal with this kind of note

[Marc Gemis]

Does a tourist information sign indicates any access rights ? Is the
fact that a place is for rent indicates any access rights to the
driveway ?  It can still be access=customers (or visitors, but we
don't have that).

m.

On Thu, Oct 5, 2017 at 10:58 AM, joost schouppe
 wrote:
> Jakka mapped it as private, based on an anonymous note. However, we now have
> clear indications this is wrong. We can't use Streetview to define this as
> access=yes, but I believe we can use this to overrule an anonymous source.
> So I have removed the tag and left a fixme and a comment at the note. I
> would suggest we only change this based on a survey or a decent reply from
> the local government.
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>

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

Re: [OSM-talk-be] Meetup about rendering of maps

[Pieter Brusselman]

@Joost,

OK, you can do that.  But I need a short intro in Github.  Maybe 
wendsday evening?



Pieter Brusselman
/Cartografie ~ Projectmedewerker/

(logo boompja) 

*A* Kasteellaan 349 A, 9000 Gent
*T* 09 / 331 59 27
*W *www.tragewegen.be

logo facebook 

ter info: ik werk niet op vrijdag

Op 5/10/2017 om 10:48 schreef joost schouppe:

Pieter,

I could make a repository on our github page https://github.com/osmbe/ 
for a QGIS project if you're interested.


2017-10-05 10:22 GMT+02:00 Jo >:


Hey, that is great news! I will also come to FOSS4G the day after
our Meetup. Somebody who uses Maperitive to render maps for the GR
guides will probably also join us on Wednesday evening.

Jo

2017-10-05 9:33 GMT+02:00 Pieter Brusselman
>:

Hi,

The last year we (trage wegen vzw) made a lot of maps based on
OSM-data using QGIS.  On octobre 26th we give a talk about
this on FOSS4G.  But I like to come to the meeting to talk
about this and sharing experience (and stylsheets :-))

Grtz,
Pieter

Pieter Brusselman
/Cartografie ~ Projectmedewerker/

(logo boompja) 

*A* Kasteellaan 349

A, 9000 Gent
*T* 09 / 331 59 27
*W *www.tragewegen.be 

logo facebook 

ter info: ik werk niet op vrijdag

Op 5/10/2017 om 9:11 schreef joost schouppe:

I like to use QGIS for basic stuff. E.g. use an open layers
background map, and some data on top of that to highlight
certain details. E.g. the maps in this diary were made with
OSM data queried from overpass and some open layers map:
http://www.openstreetmap.org/user/joost%20schouppe/diary/38103


It's also relativly easy to use QGIS for rendering OSM data
using a sqlite database (and that's easy to make within the
package, based on a .pbf file). I don't have experience
making a pretty map that way, but it can be quite useful to
make maps highlighting specific kinds of data. E.g. maps like
these are easy to make in QGIS:
http://www.openstreetmap.org/user/joost%20schouppe/diary/40267

(though here the data comes from the osm-history toolchain,
not just from a pbf file)

I think theoretically you could use QGIS and a stylesheet to
make a pretty map from scratch, but haven't seen an example
yet. And someone has been working for years on doing
something similar in ArcGIS, and I don't think he released it
yet.

2017-10-05 8:17 GMT+02:00 Jo >:

Hi,

During the next Leuven Monthly OSM Meetup I would like to
discuss rendering. I was using Maperitive in the past to
create this:


https://upload.wikimedia.org/wikipedia/commons/a/a2/Pad_van_Ad_op_OSM.png



I know. I should update that map more regularly...

Would it make sense to try and use QGIS for rendering?
Are there other solutions in the mean time?

Maybe somebody with more expertise in this would like to
come and give a demo?

Jo

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





-- 
Joost Schouppe

OpenStreetMap
 |
Twitter  | LinkedIn
 |
Meetup



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







--
Joost Schouppe
OpenStreetMap  | 
Twitter  | LinkedIn 
 | Meetup 

Re: [OSM-talk-be] How we deal with this kind of note

[joost schouppe]

Jakka mapped it as private, based on an anonymous note. However, we now
have clear indications this is wrong. We can't use Streetview to define
this as access=yes, but I believe we can use this to overrule an anonymous
source. So I have removed the tag and left a fixme and a comment at the
note. I would suggest we only change this based on a survey or a decent
reply from the local government.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Meetup about rendering of maps

[Julien Minet]

Interesting discussion!

I'm also working on rendering maps based on OSM, I use Mapnik and cartoCSS
for that --> https://github.com/nobohan/OpenArdenneMap

With QGIS, I once found this question on gis.stackexchange:
https://gis.stackexchange.com/questions/100205/error-with-existing-osm-qgis-style.
it refers to 2 projects giving qml styles for OSM data using geofabrik shp
for the first one and a spatialite database for the second one.

I'm open to discuss that on the 26th of October at the foss4g.be!

Julien



On Thu, Oct 5, 2017 at 10:22 AM, Jo  wrote:

> Hey, that is great news! I will also come to FOSS4G the day after our
> Meetup. Somebody who uses Maperitive to render maps for the GR guides will
> probably also join us on Wednesday evening.
>
> Jo
>
> 2017-10-05 9:33 GMT+02:00 Pieter Brusselman  be>:
>
>> Hi,
>>
>> The last year we (trage wegen vzw) made a lot of maps based on OSM-data
>> using QGIS.  On octobre 26th we give a talk about this on FOSS4G.  But I
>> like to come to the meeting to talk about this and sharing experience (and
>> stylsheets :-))
>>
>> Grtz,
>> Pieter
>>
>> Pieter Brusselman
>> *Cartografie ~ Projectmedewerker*
>>
>> [image: (logo boompja)] 
>>
>> *A* Kasteellaan 349
>>  A,
>> 9000 Gent
>> *T* 09 / 331 59 27
>> *W *www.tragewegen.be
>>
>> [image: logo facebook] 
>>
>> ter info: ik werk niet op vrijdag
>> Op 5/10/2017 om 9:11 schreef joost schouppe:
>>
>> I like to use QGIS for basic stuff. E.g. use an open layers background
>> map, and some data on top of that to highlight certain details. E.g. the
>> maps in this diary were made with OSM data queried from overpass and some
>> open layers map: http://www.openstreetmap.org/user/joost%20schouppe/diar
>> y/38103
>>
>> It's also relativly easy to use QGIS for rendering OSM data using a
>> sqlite database (and that's easy to make within the package, based on a
>> .pbf file). I don't have experience making a pretty map that way, but it
>> can be quite useful to make maps highlighting specific kinds of data. E.g.
>> maps like these are easy to make in QGIS: http://www.openstreetmap
>> .org/user/joost%20schouppe/diary/40267
>> (though here the data comes from the osm-history toolchain, not just from
>> a pbf file)
>>
>> I think theoretically you could use QGIS and a stylesheet to make a
>> pretty map from scratch, but haven't seen an example yet. And someone has
>> been working for years on doing something similar in ArcGIS, and I don't
>> think he released it yet.
>>
>> 2017-10-05 8:17 GMT+02:00 Jo :
>>
>>> Hi,
>>>
>>> During the next Leuven Monthly OSM Meetup I would like to discuss
>>> rendering. I was using Maperitive in the past to create this:
>>>
>>> https://upload.wikimedia.org/wikipedia/commons/a/a2/Pad_van_
>>> Ad_op_OSM.png
>>>
>>> I know. I should update that map more regularly...
>>>
>>> Would it make sense to try and use QGIS for rendering? Are there other
>>> solutions in the mean time?
>>>
>>> Maybe somebody with more expertise in this would like to come and give a
>>> demo?
>>>
>>> Jo
>>>
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>>
>>
>>
>> --
>> Joost Schouppe
>> OpenStreetMap  |
>> Twitter  | LinkedIn
>>  | Meetup
>> 
>>
>>
>> ___
>> Talk-be mailing 
>> listTalk-be@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] How we deal with this kind of note

[Jonathan Beliën]

I think it's indeed Château de Miremont !

It apparently was at some point a place we could rent to organize events ; no 
idea if it's still the case.
https://www.pagesdor.be/entreprise/Seneffe/L11523167/Ch%C3%A2teau+de+Miremont/

Jonathan Beliën
GEO-6

-Message d'origine-
De : Glenn Plas [mailto:gl...@byte-consult.be] 
Envoyé : mercredi 4 octobre 2017 18:55
À : OpenStreetMap Belgium 
Objet : Re: [OSM-talk-be] How we deal with this kind of note

It probably is Château de Miremont when checking the map.

On 04-10-17 18:50, Glenn Plas wrote:
> I can also see on the opposing side of the road a touristic sign that 
> points you toward what I think reads "Chateau de miracle" even though 
> it's blurred.
> 
> That hardly looks private.
> 
> https://www.google.be/maps/@50.5623311,4.2435211,3a,21y,117.34h,75.78t
> /data=!3m6!1e1!3m4!1sY7eetCLpKRiHgvO06v-M0Q!2e0!7i13312!8i6656
> 
> GLenn

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


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

Re: [OSM-talk-be] Meetup about rendering of maps

[joost schouppe]

Pieter,

I could make a repository on our github page https://github.com/osmbe/ for
a QGIS project if you're interested.

2017-10-05 10:22 GMT+02:00 Jo :

> Hey, that is great news! I will also come to FOSS4G the day after our
> Meetup. Somebody who uses Maperitive to render maps for the GR guides will
> probably also join us on Wednesday evening.
>
> Jo
>
> 2017-10-05 9:33 GMT+02:00 Pieter Brusselman  be>:
>
>> Hi,
>>
>> The last year we (trage wegen vzw) made a lot of maps based on OSM-data
>> using QGIS.  On octobre 26th we give a talk about this on FOSS4G.  But I
>> like to come to the meeting to talk about this and sharing experience (and
>> stylsheets :-))
>>
>> Grtz,
>> Pieter
>>
>> Pieter Brusselman
>> *Cartografie ~ Projectmedewerker*
>>
>> [image: (logo boompja)] 
>>
>> *A* Kasteellaan 349
>>  A,
>> 9000 Gent
>> *T* 09 / 331 59 27
>> *W *www.tragewegen.be
>>
>> [image: logo facebook] 
>>
>> ter info: ik werk niet op vrijdag
>> Op 5/10/2017 om 9:11 schreef joost schouppe:
>>
>> I like to use QGIS for basic stuff. E.g. use an open layers background
>> map, and some data on top of that to highlight certain details. E.g. the
>> maps in this diary were made with OSM data queried from overpass and some
>> open layers map: http://www.openstreetmap.org/user/joost%20schouppe/diar
>> y/38103
>>
>> It's also relativly easy to use QGIS for rendering OSM data using a
>> sqlite database (and that's easy to make within the package, based on a
>> .pbf file). I don't have experience making a pretty map that way, but it
>> can be quite useful to make maps highlighting specific kinds of data. E.g.
>> maps like these are easy to make in QGIS: http://www.openstreetmap
>> .org/user/joost%20schouppe/diary/40267
>> (though here the data comes from the osm-history toolchain, not just from
>> a pbf file)
>>
>> I think theoretically you could use QGIS and a stylesheet to make a
>> pretty map from scratch, but haven't seen an example yet. And someone has
>> been working for years on doing something similar in ArcGIS, and I don't
>> think he released it yet.
>>
>> 2017-10-05 8:17 GMT+02:00 Jo :
>>
>>> Hi,
>>>
>>> During the next Leuven Monthly OSM Meetup I would like to discuss
>>> rendering. I was using Maperitive in the past to create this:
>>>
>>> https://upload.wikimedia.org/wikipedia/commons/a/a2/Pad_van_
>>> Ad_op_OSM.png
>>>
>>> I know. I should update that map more regularly...
>>>
>>> Would it make sense to try and use QGIS for rendering? Are there other
>>> solutions in the mean time?
>>>
>>> Maybe somebody with more expertise in this would like to come and give a
>>> demo?
>>>
>>> Jo
>>>
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>>
>>
>>
>> --
>> Joost Schouppe
>> OpenStreetMap  |
>> Twitter  | LinkedIn
>>  | Meetup
>> 
>>
>>
>> ___
>> Talk-be mailing 
>> listTalk-be@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>>
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [OSM-talk-be] Meetup about rendering of maps

[Jo]

Hey, that is great news! I will also come to FOSS4G the day after our
Meetup. Somebody who uses Maperitive to render maps for the GR guides will
probably also join us on Wednesday evening.

Jo

2017-10-05 9:33 GMT+02:00 Pieter Brusselman :

> Hi,
>
> The last year we (trage wegen vzw) made a lot of maps based on OSM-data
> using QGIS.  On octobre 26th we give a talk about this on FOSS4G.  But I
> like to come to the meeting to talk about this and sharing experience (and
> stylsheets :-))
>
> Grtz,
> Pieter
>
> Pieter Brusselman
> *Cartografie ~ Projectmedewerker*
>
> [image: (logo boompja)] 
>
> *A* Kasteellaan 349
>  A, 9000
> Gent
> *T* 09 / 331 59 27
> *W *www.tragewegen.be
>
> [image: logo facebook] 
>
> ter info: ik werk niet op vrijdag
> Op 5/10/2017 om 9:11 schreef joost schouppe:
>
> I like to use QGIS for basic stuff. E.g. use an open layers background
> map, and some data on top of that to highlight certain details. E.g. the
> maps in this diary were made with OSM data queried from overpass and some
> open layers map: http://www.openstreetmap.org/user/joost%20schouppe/
> diary/38103
>
> It's also relativly easy to use QGIS for rendering OSM data using a sqlite
> database (and that's easy to make within the package, based on a .pbf
> file). I don't have experience making a pretty map that way, but it can be
> quite useful to make maps highlighting specific kinds of data. E.g. maps
> like these are easy to make in QGIS: http://www.
> openstreetmap.org/user/joost%20schouppe/diary/40267
> (though here the data comes from the osm-history toolchain, not just from
> a pbf file)
>
> I think theoretically you could use QGIS and a stylesheet to make a pretty
> map from scratch, but haven't seen an example yet. And someone has been
> working for years on doing something similar in ArcGIS, and I don't think
> he released it yet.
>
> 2017-10-05 8:17 GMT+02:00 Jo :
>
>> Hi,
>>
>> During the next Leuven Monthly OSM Meetup I would like to discuss
>> rendering. I was using Maperitive in the past to create this:
>>
>> https://upload.wikimedia.org/wikipedia/commons/a/a2/Pad_van_Ad_op_OSM.png
>>
>> I know. I should update that map more regularly...
>>
>> Would it make sense to try and use QGIS for rendering? Are there other
>> solutions in the mean time?
>>
>> Maybe somebody with more expertise in this would like to come and give a
>> demo?
>>
>> Jo
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
>
> --
> Joost Schouppe
> OpenStreetMap  |
> Twitter  | LinkedIn
>  | Meetup
> 
>
>
> ___
> Talk-be mailing 
> listTalk-be@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-be
>
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] autoroute à péage

[Christian Quest]

Le 5 octobre 2017 à 01:34, marc marc  a écrit :

> Au vu de l'actualité, je suis tombé sur ceci,
> avec des questions en cascade :
> https://www.openstreetmap.org/node/2298686721
> https://www.openstreetmap.org/node/2298686720
> https://www.openstreetmap.org/node/1883443861
>
> Pour les barrières :
> ne faudrait-il pas ajouter fee=yes sur la barrière au lieu de la mettre
> sur le nœud d'à côté?
> ne faudrait-il pas en conséquence de la barrière mettre toll=yes et/ou
> fee=yes sur l'autoroute ? si oui quelqu'un connaît-il la longueur
> concernée ? ou on fait une première version en mode devinette en
> fonction des péages mappés ?
>
> En passant en regardant d'autres péages, il y a un mix de tag
>
> access (l'inutile yes, le custormers à généralisé ? ou rien ?)
>
> Pour le "bâtiment" entre les barrières, quel tag ?
> j'aurais tendance à virer le tag barrière car le bâtiment n'est pas
> une barrière. sans doute ajouter un building (quelle type ?)
> convertir la date d'ouverture en start_date
> certains ont mis des amenity=vending_machine + vending=toll, cela me
> semble bien même ce n'est pas tout à fait le cas si il y un "humain"
> (même si son boulot est quasi d'imiter un robot)
> le nom : gare de péage de X ? péage de X ? il y a une grande variété
> certains font aussi un bâtiment pour le toit qui fait toute la largeur
> <> le bâtiment de la guérite (lorsqu'elle existe)
>
> Concernant le nom de l'autoroute :
> vu qu'elle a changé de N10 en A63, est-ce que cela a encore un sens
> de garder N10 dans le nom de la relation ?
> est-ce que cela a un sens d'avoir 2 relations, une + courte que
> l'autre ?
> Une utilité à avoir une relation N10 qui contient le reste de nationale
> et l'autoroute ?
>
> concernant le code postal, il y aurait une spécificité pour les péages ?
> 40410 sur la relation 123669 <> 40295 sur l'objet 1883443861
> en passant, sur les boundary, c'est postale_code et non addr:postcode
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


ça fait un peu "sur-tagging" tout ça quand même...

Le code postal sur la barrière, mais quel intérêt ? On va lui écrire ? Pour
rappel, les CP sont attribués par La Poste adresse par adresse...

access=yes... no comment

Le 3ème noeud est à reporter partiellement sur les tool_both

fee=yes... à la rigueur, on a le toll=yes sur la voirie qui suit et un
calculateur d'itinéraire utilisera cette info.

+1 pour le old_name

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

Re: [Talk-gb-westmidlands] Next meeting

[Eike Ritter]

Dear all,

I can make Thursday, 5 October but I'm unable to make Wednesdays in general.

Best wishes,

Eike

On 27/09/17 22:56, Rob Nickerson wrote:
> With two people saying no to Thursday (3 if you include me) this month,
> we might as well go for Wednesday 4th October.
> 
> For pubs those in Birmingham may know better but here are some ideas. I
> suggest the first on the list unless anyone knows a reason to rule it out.
> 
> - The gunmakers arms. Just round the corner from the bull. (seems to
> have it's own micro brewery)
> - Queen's Arms, Newhall St
> - The Shakespeare, Summer Row
> - The Wellington (no event on Wednesday / live folk music on Thursday).
> Bennetts Hill
> - The Lost and Found. Bennetts Hill
> 
> See you soon,
> 
> 
> *Rob*
> 
> On 27 September 2017 at 10:16, Andy Robinson  > wrote:
> 
> I’m easy, though in Cheshire more and more.
> 
> __ __
> 
> Cheers
> 
> Andy
> 
> __ __
> 
> *From:*Brian Prangle [mailto:bpran...@gmail.com
> ]
> *Sent:* 27 September 2017 08:15
> *To:* Rob Nickerson
> *Cc:* talk-gb-westmidlands
> *Subject:* Re: [Talk-gb-westmidlands] Next meeting
> 
> __ __
> 
> Hi Rob
> 
> No progress on alternative venue and I definitely can't make Thurs
> 5th
> 
> Regards
> 
> Brian
> 
> __ __
> 
> On 26 September 2017 at 23:59, Rob Nickerson
> >
> wrote:
> 
> Hi all,
> 
> Are we back in Birmingham for Octobers meeting? I seem to recall
> some discussion about trying a new venue. Where did we get to on
> that one?
> 
> Also I've screwed up my calendar so Thursday 5th October isn't
> looking that great for me :-( I might have to skip it but throwing
> the idea of a one off Wednesday meeting out there if that works for
> others. If not the go ahead without me on Thursday.
> 
> 
> 
> *Rob*
> 
> 
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> 
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
> 
> 
> __ __
> 
> 
> 
> 
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
> 



signature.asc
Description: OpenPGP digital signature
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

Re: [Talk-it] Import numeri civici Trento

[Andrea Musuruane]

Ciao Martin,

2017-10-04 20:07 GMT+02:00 Martin Koppenhoefer :

>
> > On 4. Oct 2017, at 10:08, Maurizio Napolitano 
> wrote:
> >
> > Della serie:
> > un utente ha inserito il civico visto sulla casa
> > un altro utente ha inserito un negozio ed ha assegnato il civico al POI.
> > Qui come ci si comporta?
>
>
> penso che dobbiamo sempre e ad ogni poi (che abbia un indirizzo) ripetere
> al meno strada e civico sul POI, perché altrimenti non abbiamo questa
> informazione (visto che non mettiamo di norma i civici ad un poligono ma ad
> un punto). Questo anche perché i negozi usano spesso soltanto uno dei vari
> civici a loro disposizione, oppure usano dei range del tipo 11/13.
>

Se capisco bene, qui dici di inserire il civico sul POI solo è questo ha
effettivamente associato il civico (ovvero nella maggior parte dei casi è
presente la targhetta del civico).

Tra l'altro inserire i tag addr:* su due punti significherebbe che ci sono
due targhette uguali su due accessi diversi, che è una cosa che nella
realtà non dovrebbe accadere (secondo le norme ISTAT).


> On 4. Oct 2017, at 19:44, Andrea Musuruane  wrote:
> >
> > Personalmente se POI e civico coincidono nell'accesso
>
>
> questo è praticamente mai corretto, perché un POI e un ingresso sono due
> cose diverse (poi nella realtà del mappatore potrebbe essere una
> scorciatoia, ammetto), e se hai un ingresso e un negozio (per esempio)
> sullo stesso oggetto vuol dire che non sai più se il nome (per esempio) è
> del negozio o dell’ingresso.
>

Qui invece mi sembra di capire che sei per separare POI e civico.

Tra l'altro ho delle difficoltà a trovare un esempio dove ci sia il nome di
un accesso. Puoi aiutarmi?


On 4. Oct 2017, at 19:44, Andrea Musuruane  wrote:
>
> Il tool dichiara che i civici sono associati ad una via non presente,
>> in realtà la via è presente: si tratta di una piazza.
>> Il problema è che la piazza è taggata come parcheggio.
>>
>
> Personalmente mi sembra che sia mappato tutto correttamente. Non sempre
> esiste una highway a cui si può dare il nome della piazza e che passa
> attraverso questa.
>
>
> una piazza sempre ha un highway se accessibile, un parcheggio sempre ha
> una strada per accedere ai posti
>

Avrei dovuto specificare meglio. Guarda l'esempio riportato da Maurizio. Le
highway ci sono ma sono highway=service + service=parking_aisle. Non mi
sembra corretto mettere il nome della piazza su di queste.

Ciao,

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

Re: [OSM-talk-be] Meetup about rendering of maps

[Pieter Brusselman]

Hi,

The last year we (trage wegen vzw) made a lot of maps based on OSM-data 
using QGIS.  On octobre 26th we give a talk about this on FOSS4G.  But I 
like to come to the meeting to talk about this and sharing experience 
(and stylsheets :-))


Grtz,
Pieter

Pieter Brusselman
/Cartografie ~ Projectmedewerker/

(logo boompja) 

*A* Kasteellaan 349 A, 9000 Gent
*T* 09 / 331 59 27
*W *www.tragewegen.be

logo facebook 

ter info: ik werk niet op vrijdag

Op 5/10/2017 om 9:11 schreef joost schouppe:
I like to use QGIS for basic stuff. E.g. use an open layers background 
map, and some data on top of that to highlight certain details. E.g. 
the maps in this diary were made with OSM data queried from overpass 
and some open layers map: 
http://www.openstreetmap.org/user/joost%20schouppe/diary/38103


It's also relativly easy to use QGIS for rendering OSM data using a 
sqlite database (and that's easy to make within the package, based on 
a .pbf file). I don't have experience making a pretty map that way, 
but it can be quite useful to make maps highlighting specific kinds of 
data. E.g. maps like these are easy to make in QGIS: 
http://www.openstreetmap.org/user/joost%20schouppe/diary/40267
(though here the data comes from the osm-history toolchain, not just 
from a pbf file)


I think theoretically you could use QGIS and a stylesheet to make a 
pretty map from scratch, but haven't seen an example yet. And someone 
has been working for years on doing something similar in ArcGIS, and I 
don't think he released it yet.


2017-10-05 8:17 GMT+02:00 Jo >:


Hi,

During the next Leuven Monthly OSM Meetup I would like to discuss
rendering. I was using Maperitive in the past to create this:

https://upload.wikimedia.org/wikipedia/commons/a/a2/Pad_van_Ad_op_OSM.png


I know. I should update that map more regularly...

Would it make sense to try and use QGIS for rendering? Are there
other solutions in the mean time?

Maybe somebody with more expertise in this would like to come and
give a demo?

Jo

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





--
Joost Schouppe
OpenStreetMap  | 
Twitter  | LinkedIn 
 | Meetup 




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


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

Re: [OSM-talk-be] Meetup about rendering of maps

[Marc Gemis]

> I think theoretically you could use QGIS and a stylesheet to make a pretty
> map from scratch, but haven't seen an example yet. And someone has been
> working for years on doing something similar in ArcGIS, and I don't think he
> released it yet.

If you mean Marc Boeringa, then no he hasn't released it yet.

m.

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

Re: [OSM-talk-be] Meetup about rendering of maps

[joost schouppe]

I like to use QGIS for basic stuff. E.g. use an open layers background map,
and some data on top of that to highlight certain details. E.g. the maps in
this diary were made with OSM data queried from overpass and some open
layers map: http://www.openstreetmap.org/user/joost%20schouppe/diary/38103

It's also relativly easy to use QGIS for rendering OSM data using a sqlite
database (and that's easy to make within the package, based on a .pbf
file). I don't have experience making a pretty map that way, but it can be
quite useful to make maps highlighting specific kinds of data. E.g. maps
like these are easy to make in QGIS:
http://www.openstreetmap.org/user/joost%20schouppe/diary/40267
(though here the data comes from the osm-history toolchain, not just from a
pbf file)

I think theoretically you could use QGIS and a stylesheet to make a pretty
map from scratch, but haven't seen an example yet. And someone has been
working for years on doing something similar in ArcGIS, and I don't think
he released it yet.

2017-10-05 8:17 GMT+02:00 Jo :

> Hi,
>
> During the next Leuven Monthly OSM Meetup I would like to discuss
> rendering. I was using Maperitive in the past to create this:
>
> https://upload.wikimedia.org/wikipedia/commons/a/a2/Pad_van_Ad_op_OSM.png
>
> I know. I should update that map more regularly...
>
> Would it make sense to try and use QGIS for rendering? Are there other
> solutions in the mean time?
>
> Maybe somebody with more expertise in this would like to come and give a
> demo?
>
> Jo
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [OSM-talk-fr] parking pour vélos et motos

[Ralf Treinen]

Bonjour,

il semble que je n'avais pas repondu à la liste :

On Fri, Sep 08, 2017 at 03:23:09PM +, marc marc wrote:
> Le 08. 09. 17 à 17:05, Nicolas Dumoulin a écrit :
> 
> >> amenity=parking + motor_vehicle=no + mofa=yes + moped=yes + 
> >> motorcycle=yes
> >> universel mais à mon avis introuvable si on cherche un parking vélo
> >> à nouveau l'occasion de tester
> > ça me semble pas mal dans le genre.
> 
> > Pourquoi pas amenity=bicycle_parking + motorcycle=yes ou l'inverse.
> 
> après l'envois de mon précédent email, je me suis demandé ce
> qui interdit à un vélo de se garer sur un parking moto.
> a mon avis rien. et donc probablement qu'un parking
> dit "2 roues" n'est rien d'autre qu'un parking moto

oui, ca me semble aussi le plus logique. Je fais donc

amenity=motorcycle_parking
bicycle=yes

-Ralf.

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

Re: [Talk-us] Someone copying from other maps

[Rihards]

On 2017.10.05. 02:25, GeoKitten wrote:
> Hello everyone. A few days ago, an OSM user in my ares (Pittsburgh, PA)
> sent me
> a private message in which they admitted to copying from two sources. First
> they said they were copying from a map of the CSX intermodal facility in
> Pittsburgh:
> "The challenging part was the CSX Intermodal facility. I took the PDF from
> their public documents on their website and extracted the engineering plan
> image, then used the PicLayers plugin to scale and orient that image
> accurately, then traced from that. I'm a little proud of that one."
> 
> Presumably this map is copyrighted so it's a serious issue.
> 
> They also said they were copying from the county address data:
> 
> "It's also a lot faster with the address points from the county overlaid
> (remangled through osmfilter, pull it out per municipality, and then rewrite
> the tags and values into OSM-appropriate format), and with some of the JOSM
> alignment tricks."
> 
> This is a government dataset that is probably public domain but whose
> copyright
> status hasn't been verified. It might be considered an unauthorized import
> though.
> 
> I'm not sure how to handle this. First of all, this was via PM so I'm
> not sure
> if I should reveal their identiy. Should I?
> 
> Second, I want to clarify that they don't appear malicious, just uninformed
> of the rules. They mentioned their copying in a positive context as if they
> didn't know it was forbidden. I don't want to be a snitch but I know the OSM
> community takes copyright issues very seriously.

it might make sense to clarify the copyright status of these sources to
see what data can be kept. in parallel, inform the user about the
problem, and email dwg.
-- 
 Rihards

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

Re: [OSM-talk-fr] Publication OpenData du cadastre

[David Marchal]

> Le 4 oct. 2017 à 18:28, Christian Quest  a écrit :
> 
> Le 04/10/2017 à 16:30, David Marchal a écrit :
>> * un truc qu’on perd, je trouve, ou alors je n’ai pas compris comment 
>> l’avoir : on ne peut plus connaître l’étendue d’un lieu-dit, ni son code 
>> FANTOIR d’ailleurs, avec les nouvelles données, car on perd le lien entre 
>> l’étiquette du lieu-dit et son emprise, et ces données ne contiennent pas le 
>> FANTOIR ;
> 
> Il y a une couche correspondant aux emprises des lieux-dits, par contre, tout 
> comme les filaires de voirie, il n'y a pas de lien avec FANTOIR... là aussi, 
> un retraitement intermédiaire serait plus utile qu'un accès direct depuis 
> JOSM.
Je crains de ne pas avoir trouvé laquelle ; j’ai trouvé les fichiers pour les 
limites de sections, de feuilles et de communes, mais pas un pour les limites 
de lieux-dits, qui sont apparemment à plusieurs par section, mais je peux me 
tromper. En plus, comme, autant que je sache, les étiquettes de lieu-dit sont 
rarement au barycentre du polygone alors que c’est censé être le cas pour 
l’import sur OSM, si on perd le lien entre l’étiquette et la limite, on a 
beaucoup de mal à vérifier le placement du nœud place=*.
> 
>> * une autre amélioration possible : si la relation des frontières de la 
>> commune est présente, donner la possibilité de télécharger en un clic tout 
>> ou partie des données publiées pour la commune, grâce au code INSEE présent 
>> dans la relation ;
> 
> Dans quel but ? Pour affichage ou pour retravailler dessus et upload ?
> Vu le volume je crains qu'on fasse de l'import sans réel affinage des données.
Pour affichage, pas pour de l’import massif, surtout sans travail dessus. 
Actuellement, il faut télécharger les différentes données manuellement, mais ça 
devrait pouvoir être automatisé si on a le code INSEE.

> Il me semble utile d'expérimenter et d'explorer ces données, mais d'être très 
> prudent dans un premier temps sur la ré-utilisation qu'on peut en faire.
> 
> Il est urgent d'attendre un peu, surtout que pas mal d'autres choses 
> devraient arriver à courte échéance et qui rendra sûrement l'exploitation des 
> EDIGEO moins intéressante.
> 
> -- 
> Christian Quest - OpenStreetMap France
Cordialement.

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

[OSM-talk-be] Meetup about rendering of maps

[Jo]

Hi,

During the next Leuven Monthly OSM Meetup I would like to discuss
rendering. I was using Maperitive in the past to create this:

https://upload.wikimedia.org/wikipedia/commons/a/a2/Pad_van_Ad_op_OSM.png

I know. I should update that map more regularly...

Would it make sense to try and use QGIS for rendering? Are there other
solutions in the mean time?

Maybe somebody with more expertise in this would like to come and give a
demo?

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