Re: [Talk-it] Curve di livello

[Cascafico Giovanni]

Ciao Michele,

per risponderti, credo ci sia bisogno di qualche informazioni in più, in
primis: dove la vuoi avere (su carta, su navigatore) e in che formato
(raster, vettoriale)?

Se ti accontenti di una mappa raster, hai provato dal portale OSM a
selezionare il livello [1]  "mappa ciclabile"?

[1] https://www.openstreetmap.org/#map=15/46.1232/13.4133=C

Il giorno mer 7 nov 2018 alle ore 07:59 Michele Malfatti <
michele.malfa...@gmail.com> ha scritto:

> Ciao a tutti volevo sapere come posso avere una mappa Osm con le curve di
> livello. Io ora esporto la mappa nel formato desiderato dal sito e poi la
> modifico con Inkscape ma mi piacerebbe avere sotto le curve di livello.
> Grazie
> Sent from my iPhone
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] POIs - Details - Gerichtsurteil

[Martin Koppenhoefer]

ich habe nicht den Eindruck dass hier noch neues gesagt wurde in den letzten 
Mails, und habe weder meine Ansichten geändert noch bin ich zum Eindruck 
gelangt dass Du überzeugt hättest werden können.

Nachdem mittlerweile mehrere andere Mapper wie Frederik, Simon und Mark 
ebenfalls herausgestellt haben, dass die Vorgaben aus der DSGVO, wie jedes 
andere Gesetz, in der Gesamtheit der Gesetze gesehen werden muss, also 
unterschiedliche Rechtsgüter abgewogen werden müssen, könntest Du Dich evtl. 
auch noch mal unabhängig informieren?

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

Re: [Talk-it] Attivazione Copernicus EMS per emergenza nelle montagne del Veneto, Trentino, Friuli-Venezia Giulia?

[Alessandro Sarretta]

Un mio piccolo aggiornamento sul tema: 
https://ilsarrett.wordpress.com/2018/11/07/copernicusems-and-flood-emergency-in-veneto-a-quick-contribution-and-feedback/


Copernicus EMS sta seguendo lo stream su Twitter 
(https://twitter.com/alesarrett/status/1060054126556577792) e vediamo se 
ci sono feedback.


2

Le immagini vengono da Sentinel, me le sono scaricate, ma penso che non 
si possa fare molto attualmente, specialmente in zone montuose, con 
immagini a quella risoluzione. Provo a tener vivo l'argomento...


Ale

On 05/11/18 19:18, liste DOT girarsi AT posteo DOT eu wrote:


Il 05/11/18 12:42, Gabriele Sani ha scritto:

Ho visto che sono stati caricati dei dati (almeno sembra). Come si puo'
dare un mano nel remapping della zona?

Grazie



La vedo dura, le foto sono piene di dati vettoriali sopra le immagini 
satellitari, non si distingue niente, mi sembra un grosso peccato, non 
si può aiutare in questo modo.




--
--

Alessandro Sarretta

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

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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

[Talk-it] Curve di livello

[Michele Malfatti]

Ciao a tutti volevo sapere come posso avere una mappa Osm con le curve di 
livello. Io ora esporto la mappa nel formato desiderato dal sito e poi la 
modifico con Inkscape ma mi piacerebbe avere sotto le curve di livello. Grazie 
Sent from my iPhone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] POIs - Details - Gerichtsurteil

[sepp1974]

Moin,

berechtigtes Interesse - "Berechtigt ist das wahrgenommene Interesse, 
wenn seine Schutzwürdigkeit von der Rechtsordnung anerkannt ist. 
Unerheblich ist, ob das Interesse öffentlicher oder privater, 
immaterieller oder vermögensrechtlicher Natur ist." eine von vielen in 
etwa gleichlautenden Definitionen zum berechtigten Interesse. Es geht 
nicht um das Interesse von OSM, eine derartige Datenbank aufzubauen, 
sondern um das berechtigte Interesse einer Person, die sich mit 
persönlichen Daten in dieser Datenbank wiederfindet, d.h. deren Daten 
erfasst, verarbeitet und dritten zur Verfügung gestellt werden. Die 
Schutzwürdigkeit dieses Interesses besagt 1. das GG und ganz explizit 
die DS-GVO. Nur dafür wurde diese Verordnung auf den Weg gebracht! 
Findet sich eine Person x in der Datenbank wieder, weil sie gemappt 
wurde, hat sie selbstverständlich ein berechtigtes Interesse an 
Information, Berichtigung oder Löschung und genau das kann OSM nicht 
leisten.


Am 07.11.2018 02:06 schrieb Mark Obrembalski:

Am 06.11.18 um 17:31 schrieb sepp1...@posteo.de:
Das berechtigte Interesse eines Verantwortlichen oder Dritten wird 
schwierig zu begründen.


Nein. OSM hat das Ziel, eine allgemein benutzbare und hilfreiche
Geodatenbank aufzubauen. Das _ist_ aber sowas von einem berechtigtem
Interesse.


Das setzt voraus, dass irgendetwas passiert ist,


Nein, ein berechtigtes Interesse setzt nicht voraus, das irgendwas 
passiert ist.


Art. 6 [1] e, 2. Halbsatz: "...ODER in Ausübung öffentlicher Gewalt 
erfolgt, die dem Verantwortlichen übertragen wurde;" (da stehen 2 
Alternativen)


Das ist aber nun kein zweiter Halbsatz, sondern eine zweite
Alternative. Öffentliche Gewalt übt OSM sicher nicht aus, aber das ist
ja auch nicht nötig, weil es ja genügt, wenn die erste Alternative
erfüllt ist. Das ist allerdings nicht sicher, ich würde mich da promär
aufs berechtigte Interesse berufen.

wobei ich mir nicht vorstellen kann, dass ein Erforderniss zur 
Verarbeitung personenbezogener Daten tatsächlich begründbar ist. Jeder 
Blick auf die OSM-Startseite widerlegt das bereits.


Was ein Blick auf die OSM-Startseite zur Entscheidung
datenschutzrechtlicher Fragen beitragen könnte, erschließt sich mir
nicht.


Dann folge mal dem Link:
"Was ist OpenStreetMap?

OpenStreetMap ist ein im Jahre 2004 gegründetes Projekt mit dem Ziel, 
eine freie Weltkarte zu erschaffen. Wir sammeln weltweit Daten über 
Straßen, Eisenbahnen, Flüsse, Wälder, Häuser und alles andere, was 
gemeinhin auf Karten zu sehen ist. Weil wir die Daten selbst erheben und 
nicht aus existierenden Karten abmalen, haben wir selbst auch alle 
Rechte daran. Die OpenStreetMap-Daten darf jeder lizenzkostenfrei 
einsetzen und beliebig weiterverarbeiten."


Mal abgesehen davon, dass "wir" keine Rechte an Personaldaten von 
Dritten haben können, werden derartige Daten gemeinhin nicht in Karten 
sichtbar gemacht. Schon allein aus diesen zwei Punkten ergibt sich die 
Verpflichtung, Personaldaten konsequent NICHT zu erfassen. Der Betreiber 
eines Franchaising-Unternehmens hat in unserer Datenbank nichts zu 
suchen, genau so wenig wie der Freiberufler, Arzt oder Rechtsanwalt 
namentlich als Betreiber/Opperator.


Ich verstehe nicht, weshalb das offenbar so schwierig zu verstehen ist?

Erfasse ich den Namen eines Geschäftes, einer Unternehmung, einer 
Praxis, was auch immer, bezieht sich dieser dadurch erschaffene 
Datensatz auf das physisch vorhandene Etwas, was durchaus legitim und 
hier völlig unstrittig erfasst, verarbeitet und bereit gestellt werden 
kann. Jede Verknüpfung mit dem Namen (des Geschäftes, der Praxis, etc.) 
über Telefonnummer, Adresse, Webseite, etc. ist legitim, weil sie sich 
auf das physisch vorhandene Etwas bezieht. Erfasse ich nun zusätzlich 
eine natürliche Person mit Namen als Betreiber/Opperator, habe ich 
widerrechtlich nach DS-GVO einen Datensatz zur Person erstellt und 
entsprechend verknüpft und genau das ist NICHT ZULÄSSIG. Darauf will ich 
hinaus!


Es ist völlig egal, ob der PRAXISNAME nun "Dr. Sommer, Augenarzt" oder 
"Augenarzt Dr. Sommer" lautet oder unter der "Gemeinschaftspraxis" noch 
die Namen und Funktionen der Ärzte stehen <= dieser Datensatz bezieht 
sich NUR auf das tatsächlich physisch vorhandene Etwas, nicht auf die 
natürliche Person (selbst wenn sie hierbei benannt ist). Es liegt doch 
am Betreiber dieses Etwas, wie er sein Geschäft, Praxis, Studio, etc. 
nennt.


Die "Augenarztpraxis Dr. Sommer" kann und soll durchaus in einer Karte 
auftauchen (um mal beim Beispiel zu bleiben), es ist aber für OSM 
absolut nebensächlich und NICHT ERFORDERLICH, eine natürliche Person mit 
diesem Datensatz zu einem physischen Objekt zu verknüpfen!


Nochmal - es geht NUR um das Feld Betreiber/Opperator in dem ganz 
konsequent KEINE NATÜRLICHE PERSON eingetragen werden darf, denn das ist 
der wiederrechtliche Datensatz nach DS-GVO. Wird darauf konsequent 
geachtet, braucht sich niemand mit Art. 6, 14, etc. DS-GVO auch nur 
ansatzweise zu 

Re: [Talk-it] Inserimento dati CAI

[Cascafico Giovanni]

+1
Per evitare il panico iniziale basta disabilitare i menu e moduli più
"spaventosi" :-)

Il mar 6 nov 2018, 23:12 Martin Koppenhoefer  ha
scritto:

>
>
> sent from a phone
>
> > On 6. Nov 2018, at 13:04, Alfredo Gattai 
> wrote:
> >
> > Se hai a disposizione un gruppo di persone preparate alle quale puoi
> fare un training intensivo ovviamente scegli un'editor potente, rapido e
> con pochi controlli automatici che ovviamente non sara' particolarmente
> user friendly
>
>
> Io penso che Josm sia user friendly. Ci sono pochi commandi con le quali
> si può fare quasi tutto il necessario in un attimo. Gli altri commandi non
> bisogna spiegare all’inizio.
> Tra gli editori OSM è decisamente quello con i più controlli automatici,
> ed è anche il più rapido soprattutto quando la connessione di rete non è
> buona.
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] California is too big ;)

[Vivek Bansal]

I told you Californians loved attention!

I picked 6 Californias because I thought it was the nicest way to divide up
the state into equally sized shapes with some reference to political
boundaries.  I also "detest" the politics of breaking up California but I
like the geospatial organization.

I don't have an opinion where a north south line would go.

That being said, (I think i'm repeating myself in a slightly different way
i'm sorry for that) alternatively would you consider adding a few of the
most populous regions and cities to the sub of California like you do for
Germany?  Just as you have an extract for Brandenberg (mit Berlin) as well
as Berlin, could you do the San Francisco Bay area as well as San
Francisco?  To make it easy, perhaps just use similar boundaries that
existed for Metro Extracts -
https://github.com/mapzen/metro-extracts/blob/master/cities.json namely:
- san-francisco-bay_california
- san-francisco_california
- san-jose_california
- los-angeles_california
- san-diego_california

There must have been a demand for those regions to be added to that list
and I think the vast majority of analyses would take place at these levels.

Thanks so much!

-Vivek

On Tue, Nov 6, 2018 at 8:11 PM Tod Fitch  wrote:

>
> > On Nov 6, 2018, at 1:58 PM, OSM Volunteer stevea <
> stevea...@softworkers.com> wrote:
> >
> > Taken "straight across the state" (west to east), following the
> political boundaries of "the northern edges of three counties"
> (admin_level=6) to break up a state (admin_level=4), it's both easy
> (technically, simply "10 counties out of 58" or "northern edges of three
> counties"), agreeable by many, a political reality right now, mostly
> straight along a similar latitude line and already somewhat harmonious
> among the relatively small sample of people here on this list who have
> something to say about it.  (Not that we're definitive, nor am I,
> personally).  But, look, we did come to a rough consensus on a relatively
> simple solution rather quickly and easily.
> >
> > I say "we've thrown it against the wall, and it seems to stick."
> (Though of course, more discussion is welcome).
> >
> > SteveA
> > California
>
> +1 to this. Seems like a reasonable place to make a division to me.
>
> Tod
> also in California
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] California is too big ;)

[Tod Fitch]

> On Nov 6, 2018, at 1:58 PM, OSM Volunteer stevea  
> wrote:
> 
> Taken "straight across the state" (west to east), following the political 
> boundaries of "the northern edges of three counties" (admin_level=6) to break 
> up a state (admin_level=4), it's both easy (technically, simply "10 counties 
> out of 58" or "northern edges of three counties"), agreeable by many, a 
> political reality right now, mostly straight along a similar latitude line 
> and already somewhat harmonious among the relatively small sample of people 
> here on this list who have something to say about it.  (Not that we're 
> definitive, nor am I, personally).  But, look, we did come to a rough 
> consensus on a relatively simple solution rather quickly and easily.
> 
> I say "we've thrown it against the wall, and it seems to stick."  (Though of 
> course, more discussion is welcome).
> 
> SteveA
> California

+1 to this. Seems like a reasonable place to make a division to me.

Tod
also in California



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [talk-au] PSMA Administrative Boundaries

[Joel H.]

How are we with our import plan on the wiki, Do we have any blockers
stopping the PSMA import?

I think we should start setting dates state-by-state for import.


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

Re: [Talk-de] POIs - Details - Gerichtsurteil

[Mark Obrembalski]

Am 06.11.18 um 17:31 schrieb sepp1...@posteo.de:
Das berechtigte Interesse eines Verantwortlichen oder Dritten wird 
schwierig zu begründen.


Nein. OSM hat das Ziel, eine allgemein benutzbare und hilfreiche 
Geodatenbank aufzubauen. Das _ist_ aber sowas von einem berechtigtem 
Interesse.


Das setzt voraus, dass irgendetwas passiert 
ist,


Nein, ein berechtigtes Interesse setzt nicht voraus, das irgendwas 
passiert ist.


Art. 6 [1] e, 2. Halbsatz: "...ODER in Ausübung öffentlicher Gewalt 
erfolgt, die dem Verantwortlichen übertragen wurde;" (da stehen 2 
Alternativen)


Das ist aber nun kein zweiter Halbsatz, sondern eine zweite Alternative. 
Öffentliche Gewalt übt OSM sicher nicht aus, aber das ist ja auch nicht 
nötig, weil es ja genügt, wenn die erste Alternative erfüllt ist. Das 
ist allerdings nicht sicher, ich würde mich da promär aufs berechtigte 
Interesse berufen.


wobei ich 
mir nicht vorstellen kann, dass ein Erforderniss zur Verarbeitung 
personenbezogener Daten tatsächlich begründbar ist. Jeder Blick auf die 
OSM-Startseite widerlegt das bereits.


Was ein Blick auf die OSM-Startseite zur Entscheidung 
datenschutzrechtlicher Fragen beitragen könnte, erschließt sich mir nicht.


Gruß,
Mark

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

Re: [Talk-de] POIs - Details - Gerichtsurteil

[Mark Obrembalski]

Am 06.11.18 um 22:00 schrieb Hartwig Alpers:



On 06.11.18 21:37, Mark Obrembalski wrote:

Am 06.11.18 um 17:51 schrieb sepp1...@posteo.de:

Selbst wenn nach Art. 6 [1] e od. f eine legitime Möglichkeit 
gefunden werden würde, scheiterts doch ganz sicher an der 
Verpflichtung zur Information nach Art. 14.


Diese Verpflichtung besteht ja nach Art. 14 Abs. 5 Buchst. b) gerade 
nicht, wenn "die Erteilung dieser Informationen sich als unmöglich 
erweist oder einen unverhältnismäßigen Aufwand erfordern würde". Wenn 
es daran also sicher scheitern würde, besteht die Pflicht gar nicht.


Es scheitert aber bei uns eher nicht an der faktischen Unmöglichkeit, 
sondern daran, daß sich niemand die Mühe macht, dem Ladeninhaber (oder 
wem immer) die Information zu erteilen.


Es gibt genau zwei Möglichkeiten:

1. Es ist mit verhältnismäßigem Aufwand möglich, den Betroffenen zu 
informieren. Dann sollten wir diesen Aufwand betreiben.


2. Es ist nicht mit verhältnismäßigem Aufwand möglich, den Betroffenen 
zu informieren. Dann dürfen wir es auch sein lassen.


Wir sollten aber ganz bestimmt nicht auf die Erfassung im Rahmen einer 
Geodatenbank sinnvoller Daten verzichten, weil das irgendwelche 
datenschutzrechtliche Informationspflichten auslösen könnte.


Gruß,
Mark


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

Re: [Talk-us] Review named junction nodes

[Harald Kliems]

Yeah, this seems to be a PA Turnpike thing. The first Maproulette task I
got was this https://www.mapillary.com/map/im/xaK6JK7CzFYTEfkAp_kwtQ
https://www.openstreetmap.org/node/345383389

 Harald.

On Tue, Nov 6, 2018 at 4:39 PM Martijn van Exel  wrote:

> I found a case[0] where the name is definitely legitimate, so I added a
> warning to double check with available street level imagery, plus an
> example to the challenge instructions.
>
> Martijn
>
> [0] https://www.openstreetmap.org/node/33991781, and see
> https://www.mapillary.com/app/?focus=photo=shRl1-KeI59im7hZSmsJig=40.21940429158758=-79.60234247987415=17=0.6058084012090132=0.35483101059177824=2.2895309990765194
>
>
>
> On Nov 6, 2018, at 1:17 PM, Martijn van Exel  wrote:
>
> Hi,
>
> I created a MapRoulette challenge to review named junction nodes. Since
> named junctions are very uncommon, most of these should probably be edited.
> There’s only a few hundred of them so we should be able to review these
> together pretty quickly.
>
> https://maproulette.org/mr3/challenge/3253/task/5881462
>
> (I also wrote a post on how to create challenges in the new MapRoulette
> because some things have changed / are new:
> https://www.openstreetmap.org/user/mvexel/diary/46863 )
>
> Let me know if this makes sense to review!
>
> Martijn
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-de] POIs - Details - Gerichtsurteil

[Martin Koppenhoefer]

sent from a phone

> On 6. Nov 2018, at 15:40, Simon Poole  wrote:
> 
> Leute, die DSGVO hat viele Regelungen, gerade wenn es um die Begründung
> von legitimen Interessen geht (Art 6.1(f)(, die verlangen das eine
> Abwägung der Interessen (die eigenen Interessen gegen die des
> Datensubjektes) stattfinden.  Sprich es hängt halt am Schluss von diesen
> Abwägungen ab ob wir etwas mit Personenbezug in die Daten aufnehmen
> sollten oder nicht


+1, reflexartig und pauschal alles was aussieht wie ein Personenname zu löschen 
wäre wie in dem Spruch mit dem Kind und dem Bade. 

Persönliche Daten gibt es vielerlei, die DSGVO nennt unter anderem 
Kommunikationsdaten, genetische Daten, medizinische Daten einschließlich denen 
zum Geisteszustand, und setzt ganz am Anfang (4.) diesen Fokus: “insbesondere 
Achtung des Privat- und Familienlebens, der Wohnung und der Kommunikation, 
Schutz personenbezogener Daten, Gedanken-, Gewissens- und Religionsfreiheit, 
Freiheit der Meinungsäußerung und Informationsfreiheit, unterneh­ merische 
Freiheit, Recht auf einen wirksamen Rechtsbehelf und ein faires Verfahren und 
Vielfalt der Kulturen, Religionen und Sprachen.”

Es geht der DSGVO in erster Linie um private Daten, wenn jemand Geschäftsführer 
einer Firma ist, oder eine Einpersonenfirma betreibt, dann ist das eher kein 
privates Datum.

Übrigens gibt es z.B. Ausnahmen für die Behörden zur „Verhütung“ von 
Straftaten, d.h. bevor überhaupt eine Straftat begangen wurde.


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

Re: [Talk-es] Importación de datos de los portales de Arganda (Madrid)

[Santiago Crespo]

Hola Pablo,

Después de leer la licencia ODC-BY, entiendo que únicamente hace falta
que el Ayuntamiento confirme oficialmente que les parece suficiente
atribución el aparecer en la página de contribuidores [1]

Tendrás que añadir una sección en esta página con un texto similar a:

"Contiene información del Portal de datos abiertos del Ayuntamiento de
Arganda del Rey que está disponible bajo la Licencia de Atribución ODC."

"Contains information from the Open Data Portal of the Town Hall of
Arganda del Rey which is made available under the ODC Attribution License."

Con los enlace correspondientes al texto completo de la licencia [2]

Cuando consigas la confirmación por parte del Ayuntamiento, súbela a la
wiki y añádela a la categoría "ES:Autorizaciones para usar fuentes de
datos de España"[3]

Una vez que resuelvas el tema de la licencia, tendrás que seguir las
import guidelines[4]. Comenta por aquí si te podemos echar una mano con
alguno de los pasos, pues el proceso puede resultar algo abrumador.

Saludos,
Santiago Crespo

[1] https://wiki.osm.org/wiki/Contributors#Spain
[2] https://opendatacommons.org/licenses/by/1.0/
[3]
https://wiki.osm.org/wiki/Category:ES:Autorizaciones_para_usar_fuentes_de_datos_de_Espa%C3%B1a
[4] https://wiki.osm.org/wiki/Import/Guidelines


On 11/6/18 1:17 AM, Iván Hernández Cazorla wrote:
> Buenas Pablo,
> Aunque estoy seguro de que muchos otros compañeros y compañeras te
> podrán dar una respuesta más detallada, te dejo por aquí un recurso
> esencial para organizar una importación acorde a las directrices de OSM [1].
> 
> De todas formas, tras revisar la ficha del conjunto de datos que
> señalas, si no me equivoco los datos están bajo la licencia ODC-By
> [2][3]. Creo que tendrías que ponerte en contacto con los encargados de
> esos datos en el Ayuntamiento de Arganda, ya que habría que solicitar
> que esos datos se compartan al menos bajo la licencia ODC. ¿Por qué? Por
> los problemas al atribuir en OSM. Fíjate en el cuadro de licencias
> compatibles con ODbL [4], en el que todas aquellas que requieren
> atribución pueden ser problemáticas.
> 
> Buscando sobre ODbL, ODC y OpenStreetMap encontré esta nota [5], que me
> parece muy útil, sobre la compatibilidad de las licencias ODbL, ODC-By,
> OGL y OS OpenData.
> 
> Tal y como te comento, seguramente otros usuarios puedan darte una
> respuesta mejor y más específica. Pero espero que esto te ayude a ir
> haciéndote a la idea.
> 
> Saludos,
> Iván
> 
> [1]: https://wiki.openstreetmap.org/wiki/Import
> [2]: http://opendefinition.org/licenses/odc-by/
> [3]:
> https://datosabiertos.ayto-arganda.es/dataset/callejero-relacion-alfabetica-de-calles-y-numeros/resource/e7bac289-6703-4f2c-8afb-0f69272e1900
> [4]: https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility
> [5]: https://osm.mathmos.net/notes/os-open-data.html
> 
> On 5/11/18 22:54, Pablo Hinojosa Nava wrote:
>> Hola a todos,
>>
>> me gustaría saber qué pasos tengo que seguir para importar en OSM los
>> datos de los portales que el Ayuntamiento de Arganda pone a disposición
>> en su portal de Datos Abiertos en la siguiente dirección: 
>>
>> https://datosabiertos.ayto-arganda.es/dataset/callejero-relacion-alfabetica-de-calles-y-numeros#
>>
>> Saludos :)
>>
>> Pablo Hinojosa.    CC58B86B
>> 
>> PabloHinojosa.is
>> 
>>
>>
>>
>> ___
>> 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 mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-us] Review named junction nodes

[Martijn van Exel]

I found a case[0] where the name is definitely legitimate, so I added a warning 
to double check with available street level imagery, plus an example to the 
challenge instructions.

Martijn

[0] https://www.openstreetmap.org/node/33991781 
, and see 
https://www.mapillary.com/app/?focus=photo=shRl1-KeI59im7hZSmsJig=40.21940429158758=-79.60234247987415=17=0.6058084012090132=0.35483101059177824=2.2895309990765194
 

 

> On Nov 6, 2018, at 1:17 PM, Martijn van Exel  wrote:
> 
> Hi, 
> 
> I created a MapRoulette challenge to review named junction nodes. Since named 
> junctions are very uncommon, most of these should probably be edited. There’s 
> only a few hundred of them so we should be able to review these together 
> pretty quickly.
> 
> https://maproulette.org/mr3/challenge/3253/task/5881462 
>  
> 
> (I also wrote a post on how to create challenges in the new MapRoulette 
> because some things have changed / are new: 
> https://www.openstreetmap.org/user/mvexel/diary/46863 
>  )
> 
> Let me know if this makes sense to review!
> 
> Martijn

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

Re: [Talk-ca] Exit with name on node *and* destination

[Martijn van Exel]

Like I said, I will leave it to the local mappers to figure out what is best.

I did refine the instructions for the U.S. challenge a little more, since there 
are definitely legitimate uses of the `name` tag on junction nodes. I included 
an example. Have a look if you’re interested: 
https://maproulette.org/mr3/challenge/3253/ 
 I hope this helps to show that a 
MapRoulette challenge is not about telling people how to map, but rather 
inviting them to have a look at a situation that may need correcting, but make 
the decision themselves.

Martijn

> On Nov 6, 2018, at 3:11 PM, Pierre Béland  wrote:
> 
> Je ne suis pas favorable à lancer une action MapRoulette. Cela ressemblerait 
> à une opération pour imposer un schema OSM particulier, voire pour mieux 
> contrôler le rendu sur la carte.
> 

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

Re: [OSM-talk-fr] Aeroports

[osm . sanspourriel]

http://tile.openstreetmap.fr/?zoom=13=44.3690=2.0270

Pourquoi pas mais :
- ici ce n'est pas un aéroport mais un aérodrome.
- il est affiché (la piste)
- dans le coin c'est plus le nom de la ville qui manque
- au zoom 15 c'est le nom de la piste qui apparaît.

Les aéroports internationaux apparaissent dès le niveau 11 :
http://tile.openstreetmap.fr/?zoom=11=48.43419=-4.39635=B00FF


Le 06/11/2018 à 22:01, denis . - ik...@hotmail.fr a écrit :

Bonsoir,

je demande avec un grand sourire que le rendu des aéroports soient 
complété.
notamment en z13 
https://www.openstreetmap.org/way/321002405#map=13/44.3690/2.0270 mais 
absent sur osm-fr


Merci.
Bonne soirée / journée..


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


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

Re: [Talk-it] Inserimento dati CAI

[Martin Koppenhoefer]

sent from a phone

> On 6. Nov 2018, at 13:04, Alfredo Gattai  wrote:
> 
> Se hai a disposizione un gruppo di persone preparate alle quale puoi fare un 
> training intensivo ovviamente scegli un'editor potente, rapido e con pochi 
> controlli automatici che ovviamente non sara' particolarmente user friendly


Io penso che Josm sia user friendly. Ci sono pochi commandi con le quali si può 
fare quasi tutto il necessario in un attimo. Gli altri commandi non bisogna 
spiegare all’inizio.
Tra gli editori OSM è decisamente quello con i più controlli automatici, ed è 
anche il più rapido soprattutto quando la connessione di rete non è buona.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-ca] Exit with name on node *and* destination

[Pierre Béland]

Je ne suis pas favorable à lancer une action MapRoulette. Cela ressemblerait à 
une opération pour imposer un schema OSM particulier, voire pour mieux 
contrôler le rendu sur la carte.

J'ai modifié au cours des dernières années ces objets et les noms y sont 
revenus. Peut-être vaut-il mieux alerter les communautés locales et leur 
laisser le temps de décider quoi faire ?
Pierre

   Le mardi 6 novembre 2018 14 h 12 min 01 s HNE, Martijn van Exel 
 a écrit : 

 I did create a MapRoulette challenge to review these named junction nodes for 
the United States just now. See 
https://maproulette.org/mr3/challenge/3253/task/588146c. If you find it useful 
I’d be happy to create one for Canada as well. Or show you how you can do it 
yourself.

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

Re: [Talk-us] California is too big ;)

[OSM Volunteer stevea]

Simon Poole  wrote:
> I think the question is less where N vs S California is but more if
> there is a regional split of California that would make sense from a
> processing pov. Is for example somebody likely to do something with a
> North-CA extract, or if you would want to do something on a smaller
> scale, would that clearly be at a county level. Frederik is likely to
> groan at that idea, but some how I suspect that CA county level extracts
> would be comparable with states in other countries.

Simon, I hear you, yet "processing" is what would happen data-wise after this 
split, yet it's also what Californians do in their brains when they hear of or 
think of "Northern"  vs. "Southern:"  we tend to think right around that 
"pretty close to straight line" (it's not, though it's darn close, and it looks 
straight on a larger-scale county map) we are all huddling around as "about" 
where the chop is or should be.  Remember, Frederik's ask is for a sensible 
methodology to break apart something that is now or soon "too big."  Basic 
computer science implies a binary "chop it in half" approach (for now, we can 
do this again, and again...), which is exactly what we're doing.

And, nothing stops anybody from "drilling down" to a county level (or deeper) 
if, as you say, they want to "do something smaller."

I'm a couple of counties away from SLO and know people who live there, work 
there and go to university there; SLO really is a "could go either way" case, 
which makes it a good place to at least start to define (beginning at the 
ocean) a "north-south boundary" of sorts (the only sort of binary chop that 
makes sense:  nobody realistically talks about "Western California" or "Eastern 
California" though "the coast" is both a useful demographic/population concept 
and a geographical reality, however, much fuzzier about "how far inland" is 
meant by "the coast").

Taken "straight across the state" (west to east), following the political 
boundaries of "the northern edges of three counties" (admin_level=6) to break 
up a state (admin_level=4), it's both easy (technically, simply "10 counties 
out of 58" or "northern edges of three counties"), agreeable by many, a 
political reality right now, mostly straight along a similar latitude line and 
already somewhat harmonious among the relatively small sample of people here on 
this list who have something to say about it.  (Not that we're definitive, nor 
am I, personally).  But, look, we did come to a rough consensus on a relatively 
simple solution rather quickly and easily.

I say "we've thrown it against the wall, and it seems to stick."  (Though of 
course, more discussion is welcome).

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

Re: [Talk-us] California is too big ;)

[Joseph Eisenberg]

Counties in California are very different in size and population. A few in
the mountains have under 20,000 people and a rather small area. But Los
Angeles county has 10 million people and covers a huge area.

If 2 files become too big in a few years, it would be most useful to break
up the states into metropolitan statistical areas plus rural regions, but I
think this can wait. In the meantime NorCal / SoCal will work.
On Wed, Nov 7, 2018 at 6:29 AM Simon Poole  wrote:

> Jumping in here slightly unwarranted, but what the heck :-).
>
> I think the question is less where N vs S California is but more if
> there is a regional split of California that would make sense from a
> processing pov. Is for example somebody likely to do something with a
> North-CA extract, or if you would want to do something on a smaller
> scale, would that clearly be at a county level. Frederik is likely to
> groan at that idea, but some how I suspect that CA county level extracts
> would be comparable with states in other countries.
>
> Simon
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] California is too big ;)

[Simon Poole]

Jumping in here slightly unwarranted, but what the heck :-).

I think the question is less where N vs S California is but more if
there is a regional split of California that would make sense from a
processing pov. Is for example somebody likely to do something with a
North-CA extract, or if you would want to do something on a smaller
scale, would that clearly be at a county level. Frederik is likely to
groan at that idea, but some how I suspect that CA county level extracts
would be comparable with states in other countries.

Simon




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

Re: [Talk-de] POIs - Details - Gerichtsurteil

[sepp1974]

Ganz richtig!

Hinzu kommt, dass im Falle eines möglichen und berechtigten 
Widerspruches niemand ausschließen kann, dass der Datensatz nicht in 
Zukunft erneut erstellt werden kann. Zum einen fehlen hierfür die techn. 
Voraussetzungen, das zu unterbinden, zum anderen die Möglichkeit, das 
automatisiert zu kontrollieren. Hinzu kommt - wenn ich das richtig 
verstanden habe (?) - dass ein einmal erfasster Datensatz zum Zwecke der 
Nachvollziehbarkeit von Änderungen immer im Archiv reproduzierbar 
bleibt, richtig?


Gruß Sepp

Am 06.11.2018 22:00 schrieb Hartwig Alpers:

On 06.11.18 21:37, Mark Obrembalski wrote:

Am 06.11.18 um 17:51 schrieb sepp1...@posteo.de:

Selbst wenn nach Art. 6 [1] e od. f eine legitime Möglichkeit 
gefunden werden würde, scheiterts doch ganz sicher an der 
Verpflichtung zur Information nach Art. 14.


Diese Verpflichtung besteht ja nach Art. 14 Abs. 5 Buchst. b) gerade 
nicht, wenn "die Erteilung dieser Informationen sich als unmöglich 
erweist oder einen unverhältnismäßigen Aufwand erfordern würde". Wenn 
es daran also sicher scheitern würde, besteht die Pflicht gar nicht.


Es scheitert aber bei uns eher nicht an der faktischen Unmöglichkeit,
sondern daran, daß sich niemand die Mühe macht, dem Ladeninhaber (oder
wem immer) die Information zu erteilen.

Viele Grüße
Hartwig

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


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

[Talk-de] Kandidatur für den OSMF-Vorstand

[Tobias Knerr]

Hallo zusammen,

ich habe dieses Wochenende erfahren, dass Peda (Peter Barth) aus dem
Vorstand der OSMF ausscheiden und nicht erneut kandidieren wird. Peda
hat aus meiner Sicht einiges erreicht, was das reibungslose
Funktionieren unseres Projekts, die Transparenz der Arbeit des Boards
(z.B. durch öffentliche Vorstandssitzungen und die Veröffentlichung von
Abstimmungsergebnissen), das Bekenntnis zu freier Software und offenen
Kommunikationsplattformen und nicht zuletzt die Vertretung der
Interessen von ehrenamtlichen Mappern angeht. Ich glaube, dass Peda auch
deshalb wertvoll für die Community war, weil er derzeit als einziges
Boardmitglied keiner Firma oder humanitären Organisation mit
geschäftlichen Interessen an OSM angehört. Für seine gute Arbeit möchte
ich ihm hiermit herzlich danken!

Da es mir wichtig ist, dass diese gute Arbeit auch in den kommenden
Jahren fortgeführt werden kann, werde ich mich für den Vorstand der OSMF
zur Wahl stellen. Ich bin in der OSMF seit 2009 Mitglied und auch in
einigen OSMF-Arbeitsgruppen gelegentlich aktiv. Vor allem aber bin ich
seit langem als Mapper und inzwischen auch als Hobby-Entwickler in der
OSM-Community zu Gange. Auch aus dem Forum oder Wiki dürften mich einige
von euch schon kennen.

Ausführlichere Infos liefere ich später noch nach, auch über die
offiziellen Kanäle: Es soll auch dieses Mal wieder Wahlprogramme sowie
die Möglichkeit zum Einreichen von Fragen an die Kandidaten geben. Da
die Vorstandswahl im deutschen Forum dank der fleißigen
Mitgliederwerbung von Nakaner aber bereits Gesprächsthema ist, wollte
ich den sprichwörtlichen Hut schon einmal in den Ring werfen. Und
natürlich dürft ihr mich auch jetzt schon mit Vorschlägen, Kritik und
Fragen löchern!

Viele Grüße,
Tobias

( Crossposting von https://forum.osm.org/viewtopic.php?id=64360 )

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

Re: [Talk-de] POIs - Details - Gerichtsurteil

[sepp1974]

Mark,

es geht um den Datensatz des Betreibers/Opperators, nicht um den 
Firmennamen oder Namen bspw. der Praxis - das ist soweit geklärt denke 
ich, selbst wenn der (Prixis-)Name, den Namen des Arztes enthält.


"Augenarztpraxis Dr. Sommer" ist kein personenbezogener Datensatz 
sondern Eigenname der Praxis = unstrittig m.M.n., es darf dann nur nicht 
zusätzlich noch Dr. Sommer als betreiber gemappt werden, denn über das 
Feld wird der Bezug zur Person des Dr. Sommer hergestellt.




Die Absätze 1 bis 4 finden keine Anwendung, wenn und soweit

adie betroffene Person bereits über die Informationen verfügt,
bdie Erteilung dieser Informationen sich als unmöglich erweist oder 
einen unverhältnismäßigen Aufwand erfordern würde; dies gilt 
insbesondere für die Verarbeitung für im öffentlichen Interesse liegende 
Archivzwecke, für wissenschaftliche oder historische Forschungszwecke 
oder für statistische Zwecke vorbehaltlich der in Artikel 89 Absatz 1 
genannten Bedingungen und Garantien oder soweit die in Absatz 1 des 
vorliegenden Artikels genannte Pflicht voraussichtlich die 
Verwirklichung der Ziele dieser Verarbeitung unmöglich macht oder 
ernsthaft beeinträchtigt In diesen Fällen ergreift der Verantwortliche 
geeignete Maßnahmen zum Schutz der Rechte und Freiheiten sowie der 
berechtigten Interessen der betroffenen Person, einschließlich der 
Bereitstellung dieser Informationen für die Öffentlichkeit,

c...

OSM ist kein Archiv, wissenschaftliche oder historische Forschung möchte 
ich auch ausschließen, Statistik ebenso - damit fällt diese Regelung aus 
und OSM unterliegt klar Art. 14 Abs. 1 ff. - zum Ausschluss dieser 4 
möglichen Alternativen bitte mal die Beschreibung von OSM inkl. der 
Satzung des e.V. lesen. Wo ist der Forschungsauftrag zum 
personenbezogenen Datensatz? Wo sind bisherige Forschungsergebnisse? Was 
wird (tatsächlich) erforscht? Die Bedingungen zu Art. 89 Abs. 1 werden 
auch nicht umgesetzt - damit fällt OSM sowieso raus! OSM ist eine 
Datenbank im Livebetrieb, welche die Verarbeitung aller Daten (inkl. 
erfasster personenbezogener Daten) innerhalb der Datenbank im 
Livebetrieb durch jedermann ermöglicht und darüber hinaus, jede 
automatisierte Datennutzung an Drittnutzer bereitstellt.


Gruß Sepp





Am 06.11.2018 21:37 schrieb Mark Obrembalski:

Am 06.11.18 um 17:51 schrieb sepp1...@posteo.de:

Selbst wenn nach Art. 6 [1] e od. f eine legitime Möglichkeit gefunden 
werden würde, scheiterts doch ganz sicher an der Verpflichtung zur 
Information nach Art. 14.


Diese Verpflichtung besteht ja nach Art. 14 Abs. 5 Buchst. b) gerade
nicht, wenn "die Erteilung dieser Informationen sich als unmöglich
erweist oder einen unverhältnismäßigen Aufwand erfordern würde". Wenn
es daran also sicher scheitern würde, besteht die Pflicht gar nicht.

Ich warte immer noch auf ganz konkrete Beispiele, wozu 
personenbezogene Daten in dieser Datenbank wichtig wären, das es sich 
lohnt, eine derartigen gesetzlichen Spagat hinzulegen.


Nehmen wir einfach mal nur die Arztpraxis mit Praxisschild vor der
Tür. Die Praxis tritt genau unter dem Namen des Praxisinhabers auf.
Die bloße Information, wo sich Arztpraxen befinden, nützt wenig, wenn
man eine bestimmte sucht. Gleiches gilt für jede Menge andere
Freiberufler.

Gruß,
Mark

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


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

Re: [Talk-it] Inserimento dati CAI

[Francesco Pelullo]

Il giorno lun 5 nov 2018, 23:21 Luca Delucchi  ha
scritto:

>
> > Riguardo al formato voto per lo Shapefile, abbastanza comodo per essere
> importato con il plugin Open Data.
>
> per ora dello shapefile non ce n'è bisogno visto che le tracce non
> hanno informazioni alfanumeriche, comunque puoi crearti uno shapefile
> con QGIS importando il WFS e salvandolo come shapefile
>

In bocca al lupo! :-)

Siamo quasi nel 2019, sarebbe ora di cestinare il formato shapefile.

Esportando da un WFS in uno shapefile, avresti problemi con:
- nomi dei campi troncati a 10 caratteri;
- nessun supporto alla topologia (le geometrie sono semplici "linee"
disegnate una accanto all'altra);
- valori NULL trasformati in 0;
- tipi di campi dati limitati e poco utilizzabili (ad esempio QLONG
archiviato come TEXT);
- indice spaziale da creare a mano;
- charset non definito, problemi con accentate, umlaut...

Ciao
/niubii/

P.S.: scusate per il pippone, sto combattendo una battaglia in ufficio per
cercare di abbandonare il formato shapefile (e la sto perdendo).

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

[OSM-talk-fr] Aeroports

[denis .]

Bonsoir,

je demande avec un grand sourire que le rendu des aéroports soient complété.
notamment en z13 
https://www.openstreetmap.org/way/321002405#map=13/44.3690/2.0270 mais absent 
sur osm-fr

Merci.
Bonne soirée / journée..
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] POIs - Details - Gerichtsurteil

[Hartwig Alpers]

On 06.11.18 21:37, Mark Obrembalski wrote:

Am 06.11.18 um 17:51 schrieb sepp1...@posteo.de:

Selbst wenn nach Art. 6 [1] e od. f eine legitime Möglichkeit 
gefunden werden würde, scheiterts doch ganz sicher an der 
Verpflichtung zur Information nach Art. 14.


Diese Verpflichtung besteht ja nach Art. 14 Abs. 5 Buchst. b) gerade 
nicht, wenn "die Erteilung dieser Informationen sich als unmöglich 
erweist oder einen unverhältnismäßigen Aufwand erfordern würde". Wenn 
es daran also sicher scheitern würde, besteht die Pflicht gar nicht.


Es scheitert aber bei uns eher nicht an der faktischen Unmöglichkeit, 
sondern daran, daß sich niemand die Mühe macht, dem Ladeninhaber (oder 
wem immer) die Information zu erteilen.


Viele Grüße
Hartwig

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

Re: [OSM-talk-fr] Projet du mois de novembre: gendarmerie/police

[Cédric Frayssinet]

Bonsoir,

Comment sont gérées les épingles ? En effet, hier, j'ai rajouté de
nombreuses gendarmeries dans ce secteur :
https://osmose.openstreetmap.fr/en/map/#item=8191=500=3=11=44.3626=2.4478==
; et j'ai donc cliqué sur le bouton vert pour les faire disparaître.

Aujourd'hui, ces épingles sont réapparues avec un texte 'issus reported
on 2018-11-04', hier, nous étions le 5 hier. Faut-il une nouvelle analyse ?

De plus, j'ai remarqué au moins 3 gendarmeries en Aveyron dont les
coordonnées GPS sont KO, l'épingle est sur l'ancienne gendarmerie mais
OSMOSE et donc le fichier OpenData indique la nouvelle adresse. Il faut
donc localiser la nouvelle et souvent dessiner ; d'ailleurs que met-on
sur l'ancienne parcelle ?

Je mets entre 5 et 10 mn avec iD pour rajouter une gendarmerie, je
suppose qu'avec JOSM, c'est plus rapide, notamment avec l'ajout en masse
des tags.

Cédric

PS : bravo aux contributeurs de la région parisienne, y a plus bcp
d'épingles dans ce secteur :)



Le 05/11/2018 à 21:21, Noémie Lehuby a écrit :
>
> Hello,
>
> Déjà 5 jours de ce #ProjetDuMoisOSM, voici un premier bilan chiffré :
>
> Près de 700 commissariats ou gendarmeries ont été créés !
>
> D'après les chiffres publiés en opendata par le Ministère de
> l'Intérieur, nous avons actuellement, à la louche, un sixième de
> commissariats de Police Nationale, et un tiers des gendarmeries.
> (je n'ai pas trouvé de source officielle pour un nombre de
> commissariats de police municipale, n'hésitez pas si vous avez ça sous
> la main)
>
> Bref, on va dans la bonne direction, il faut maintenir le rythme !
> N'hésitez pas à partager vos astuces ici ou en complétant la page du
> projet du mois
> 
> ;)
>
> -- 
> Noémie Lehuby
> Le 04/11/2018 à 22:26, Vincent de Château-Thierry a écrit :
>> Bonsoir,
>>
>>> De: "Noémie Lehuby" 
>>>
>>> Le 04/11/2018 à 11:26, lenny.libre a écrit :
 +1 avec Vincent, du fait de la présence des polices municipales
 même s'il n'est pas très utilisé, mais il faudrait définir si on utilise
 la valeur "police_municipale" ou "police municipale"
>>> C'est un peu dommage de devoir créer un nouveau tag juste pour
>>> regrouper les polices municipales (vu qu'operator fait bien l'affaire pour 
>>> les
>>> deux autres) mais pourquoi pas, ça fait sens.
>>> Je vais laisse modifier la page FR:amenity=police et on voit comment
>>> on peut l'inclure dans notre #projetOSMDuMois en cours ?
>> J'ai modifié la page FR:amenity=police, en optant pour les valeurs "police", 
>> "gendarmerie" et "police_municipale". On pourra changer cette dernière 
>> ensuite s'il y a débat, mais au moins on construit une typologie des 
>> organismes avec un tag ad'hoc.
>>
>> vincent
>>
>> ___
>> 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


-- 
Dégooglisé !  - Sociétaire Enercoop
, l'énergie militante

Sur Mastodon : @bristow...@framapiaf.org 

Promouvoir et soutenir le logiciel libre 

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

[Talk-us] Proposed building import in Hamilton County, Ohio

[Nate Wessel]

Below is a link to a proposed import for building footprints (with some 
address tags, height info, etc.) in Hamilton County Ohio.


https://wiki.openstreetmap.org/wiki/Hamilton_County_Building_Import

We've been planning this on the OSM Ohio slack channel, but I figured I 
should reach out here in case anyone is interested but not on there! I'd 
love some feedback on the proposal or any offers of help with the actual 
import once it starts.


Best,

Nate Wessel


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

Re: [Talk-it] Inserimento dati CAI

[Volker Schmidt]

Secondo delle discussioni in lista talk-it le mappe IGM 25000 da anni o
addirutara da decenni non vengono più aggiornate.
Vedi http://lists.openstreetmap.org/listinfo/talk-it del 2013 oggetto:
[Talk-it] IGM su Josm
(Non ho controllato personalmente)
Volker

On Tue, 6 Nov 2018 at 13:54, Max  wrote:

> Grazie per i consigli Alfredo, non avevo mai preso in considerazione il
> Protlach, lo proverò e sulla base dei feedback di quest'anno sceglierò
> l'editor più adatto per il corso del prossimo anno.
>
> Anche sul Locus si ha la possibilità di importare layer WMS, e quindi di
> usare carte tecniche regionali e carta IGM 25000, molto importante per noi
> a sud dal momento che qui quasi non esistono carte escursionistiche di
> facile reperibilità.
>
> Riguardo la scelta dell'app su cui basare il corso nella mia sezione CAI,
> ho preferito il Locus per una feature molto importante per fare rilievi sul
> campo ai fini della mappatura su OSM: durante la registrazione della
> traccia è possibile aggiungere in modo semplice e rapido waypoint di tipo
> vocale, fotografico o video, con possibilità di esportare traccia e
> waypoint in un unico package KMZ. Non sono riuscito a trovare una
> funzionalità analoga e altrettanto comoda su Oruxmap, Alpine Quest, ecc. ma
> magari mi sbaglio...
>
> Altri punti di forza di Locus rispetto ai suoi competitor (tutti ottimi a
> dire il vero) sono la possibilità di georeferenziare rapidamente e
> utilizzare come layer scansioni o fotografie di mappe (per esempio foto
> scattate al volo su pannelli informativi), e una funzione di pianificazione
> del percorso molto ben fatta che consente ad esempio di verificare sul
> campo i tempi di percorrenza di un percorso alternativo durante
> l'escursione.
>
> Max
>
> Il giorno mar 6 nov 2018 alle ore 13:09 Alfredo Gattai <
> alfredo.gat...@gmail.com> ha scritto:
>
>> Ce ne sono si e se qualcuno e' abituato con quelle continui pure. Io in
>> fase di pianificazione uso molto Orxumap perche' ci carico sotto tutte le
>> CTR della mia regione e vedo dove sono vecchi tracciati che ora sono
>> invisibile. Georesq pero' ha il vantaggio che per l'attivita'
>> escursionistica e per il semplice rilievo di chi fa monitoraggio e' piu'
>> semplice ed immediato. Ora poi che sono stati risolti i problemi di consumo
>> batteria e ci sono anche le mappe off-line va decisamente bene.
>>
>> Alfredo
>>
>> On Tue, Nov 6, 2018 at 11:55 AM Max  wrote:
>>
>>> Si, ho consigliato di usare sempre il GeoResQ in background e in
>>> modalità tracciamento oltre che per le richieste di aiuto, ma per mappe e
>>> strumenti GPS disponibili IMHO ci sono app più funzionali e complete come
>>> il locus map da usare in foreground rispetto al GeoResQ.
>>>
>>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] POIs - Details - Gerichtsurteil

[Mark Obrembalski]

Am 06.11.18 um 17:51 schrieb sepp1...@posteo.de:

Selbst wenn nach Art. 6 [1] e od. f eine legitime Möglichkeit gefunden 
werden würde, scheiterts doch ganz sicher an der Verpflichtung zur 
Information nach Art. 14.


Diese Verpflichtung besteht ja nach Art. 14 Abs. 5 Buchst. b) gerade 
nicht, wenn "die Erteilung dieser Informationen sich als unmöglich 
erweist oder einen unverhältnismäßigen Aufwand erfordern würde". Wenn es 
daran also sicher scheitern würde, besteht die Pflicht gar nicht.


Ich warte immer noch auf ganz konkrete Beispiele, wozu personenbezogene 
Daten in dieser Datenbank wichtig wären, das es sich lohnt, eine 
derartigen gesetzlichen Spagat hinzulegen.


Nehmen wir einfach mal nur die Arztpraxis mit Praxisschild vor der Tür. 
Die Praxis tritt genau unter dem Namen des Praxisinhabers auf. Die bloße 
Information, wo sich Arztpraxen befinden, nützt wenig, wenn man eine 
bestimmte sucht. Gleiches gilt für jede Menge andere Freiberufler.


Gruß,
Mark

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

[Talk-us] Review named junction nodes

[Martijn van Exel]

Hi, 

I created a MapRoulette challenge to review named junction nodes. Since named 
junctions are very uncommon, most of these should probably be edited. There’s 
only a few hundred of them so we should be able to review these together pretty 
quickly.

https://maproulette.org/mr3/challenge/3253/task/5881462 
 

(I also wrote a post on how to create challenges in the new MapRoulette because 
some things have changed / are new: 
https://www.openstreetmap.org/user/mvexel/diary/46863 
 )

Let me know if this makes sense to review!

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

Re: [Talk-us] California is too big ;)

[L. David Baron]

As another Californian (from the SF Bay Area) with some amount of
opinion here, I suppose I'll chime in.

The straight-ish line (northern boundaries of San Luis Obispo, Kern,
and San Bernardino counties) seems largely reasonable to me as a
possible North/South two-way split.

(Other possible splits are a 3-way North/Central/South split as the
official wine regions do ("North Coast AVA", "Central Coast AVA",
"South Coast AVA"), or a 4-way split as the federal judicial
districts do (Eastern/Northern/Central/Southern), but I think both
of those, particularly the 3-way that splits the San Francisco Bay
Area in half, involve more awkward decisions.  Note that the 4-way
judicial split aligns with the proposed 2-way split with the
exception of Kern county.)

The counties that feel most ambiguous to me in the North/South split
we're discussing are perhaps:

 - San Luis Obispo, which Luis wrote about

 - Kern, which is part of the central valley but in this split falls
   as the only central valley county in the south half of the split

 - Inyo and maybe even Mono counties, east of the Sierras, which are
   perhaps better connected to San Bernardino county to their south
   than to the Central Valley on the other side of the Sierras.

but I don't have any particular local knowledge of these parts of
California.  The article
https://en.wikipedia.org/wiki/Southern_California reflects the first
two ambiguities, but
https://en.wikipedia.org/wiki/Northern_California does not reflect
any.  I'd note that district lines drawn in
https://en.wikipedia.org/wiki/California%27s_congressional_districts
seem to pull Kern county to the north, and Inyo and Mono to the
south.


The one other thought is that the Northern/Southern split may be
somewhat awkward to outsiders looking at a map of California, who
may be surprised that a point 35% of the way from California's
southern border to its northern border would count as Northern
California.

That said, I guess if California needs to be split, the two-way
split at this straight-ish line seems like it may be the most
straightforward option.

-David


On Tuesday 2018-11-06 10:27 -0500, Greg Troxel wrote:
> Luis Villa  writes:
> 
> >> My guess is the only split that the majority in the state would instantly
> >> recognize would be “Northern California” and “Southern California”. However
> >> exactly where that split occurs is likely to be contested. :)
> >>
> >> Were I to hazard a guess, I would start on the coast somewhere around San
> >> Luis Obispo
> >
> > I think Tod is correct here that north/south is the only split most
> > Californians would recognize, and that the dividing line is not consistent.
> > (You might also get a "Central California" from some folks, but the
> > dividing lines there would be similarly fuzzy.) My wife grew up in San Luis
> > Obispo, and people from LA tend to say she's from Northern California and
> > San Franciscans say she's from Southern California.
> 
> I'm someone who has only been to California occasionally, and for me
> also the north/south split is the one that seems the most likely for
> many to be able to grasp.
> 
> I have never heard of "six californias" in any coherent way; it seemed
> new on reading.  And I would have little clue about the edges of those
> boundaries even seeing the list of names.  So I think that's not a good
> idea, because split extracts need to target being understood by
> nonlocals.
> 
> I would of course recommend listening to locals about exactly shere
> between SF and LA the line is, and I would align to counties so that
> each county is in north or south, and have the east-west line more or
> less try to follow latitude from the breakpoint from the coast.
> 
> With a N/S split like we are converging on, most users that are ok with
> half will guess right the first time, and people that care about areas
> near the border will get it that they are near the border and need both
> or the whole thing.
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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

Re: [OSM-talk-fr] Ajout d'aménagements cyclable avec StreetComplete

[Antoine Riche]

Le 05/11/2018 à 12:29, marc marc a écrit :

Le 05. 11. 18 à 11:35, Axelos a écrit :

identifier les doublons

c'est bien cela le soucis.
il faudrait un tag genre cycleway=separate
qui indique que cet élément est déjà renseigné
mais par un autre objet à la manière de sidewalk=separate


Coïncidence, j'ai découvert aujourd'hui l'existence de 
cycleway=separate, documenté sur 
https://wiki.openstreetmap.org/wiki/Key:cycleway#Other_values. Seulement 
384 occurrences pour l'instant, mais le principe est simple et efficace.


Utiliser ce tag résout le problème évoqué avec StreetComplete, qui 
élimine de sa quête les voies portant le tag cycleway. En savoir plus : 
https://github.com/westnordost/StreetComplete/issues/1250


A noter aussi cycleway=shoulder (accotement en anglais), plus utilisé 
avec 2349 occurrences. Le wiki n'est pas très clair, j'imagine qu'il 
s'agit de routes disposant d'un accotement non réservé aux cyclistes 
mais les mettant en relative sécurité.


Antoine.




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

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

Indeed, a mapper who wants to add this and who can't find the information
on the internet or in a booklet, would have travel to the first stop, take
note of all the departure times and then establish the deltas between all
the stops of the itinerary.
If that's the case, such a mapper would probably better use the tags based
method on the route relations.

It all depends on how much detail you want to add (and maintain in the long
run).

Another weakness of the relation pet stop/route pair method is that it will
be very hard to encode the exceptions; not on Wednesdays, only on Fridays,
etc.

Jo

Op di 6 nov. 2018 om 20:22 schreef djakk djakk :

> Ok I see.
>
> I am still a bit reluctant to your proposal since the travelling time
> between 2 stops can vary during the day, especially for train routes.
> Ok there is the possibility of adding a new timetable relation ...
>
> Moreover, I think that data inputs from the ground can not be done with
> your proposal (it needs to know the timetable for the whole line), we’ll
> depend on GTFS file actually :-/
>
> Julien “djakk”
>
>
>
> Le mar. 6 nov. 2018 à 19:27, Jo  a écrit :
>
>> Yes, very hard to debug and we already established some change every few
>> months. So after a change from the operator. One traveler will update one
>> of those schedules, Another may do so for 3 stops down the line, in the
>> mean time the stops in between and after are not updated yet. A maintenance
>> nightmare. The way I proposed it, suffers less from that problem. When
>> timetables change it's usually that trips are added or removed or their
>> start time changes slightly. The time to get from one stop to the next will
>> remain constant, most of the time.
>>
>> Jo
>>
>> Op di 6 nov. 2018 om 18:40 schreef djakk djakk :
>>
>>> I don’t get it ...
>>>
>>> With my point of view, one route with 15 stops has 15 timetables, each
>>> timetable describes the arrival time and the departure time of several
>>> trips at the stop.
>>>
>>> There must be the same number of trips along the stops’ timetables.
>>> (Otherwise this is an other route).
>>>
>>> You mean, if somebody messed up and add an extra trip inside a
>>> timetable, this would be hard to figure ?
>>>
>>> Julien “djakk”
>>>
>>>
>>> Le mar. 6 nov. 2018 à 18:30, Jo  a écrit :
>>>
 If you have a single one for a stop/route pair, no problem. As soon as
 you have a few hundred and the information in them starts to conflict with
 other another timetable relation for the same route it will be extremely
 hard to figure out where it went wrong.

 Polyglot

 Op di 6 nov. 2018 om 17:08 schreef djakk djakk :

> In which case a timetable per stop and per route is unmaintable ?
>
> Julien “djakk”
>
>
> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a
> écrit :
>
>> I think it is important to have an osm object describing the
>> timetable user-oriented for simple editing without any tool.
>> The mapper is at a bus stop, takes a picture of the timetable, can
>> import it later in osm without the need of any extra tool.
>> Validator can be inside a tool.
>>
>> Julien « djakk »
>>
>>
>> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
>> écrit :
>>
>>> Almost that ! Sometimes bus stops does not have their official
>>> timetable, the user have to refer to the closest previous bus stop 
>>> having
>>> an official timetable. So this kind of bus stop may not have a 
>>> timetable in
>>> osm (except an osm mapper really wants to put it into osm, knowing per
>>> habits the schedule).
>>>
>>>
>>> Julien « djakk »
>>>
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>>
 You mean per stop/route pair? That's an incredible s amount of
 relations! It seems to me that it would be a nighmare to try and 
 maintain
 it that way. At first sight it seems simpler, but with the new 
 proposal i
 came up with, you can see how the stops of a variation in itinerary tie
 together.

 If the vehicle remains in the station longer, the roles could
 become 00:30-00:35 instead of simply 00:35 for the departure offset to 
 the
 time the vehicle left at its first stop.

 Seeing the stops in the timetable relation in the order they are
 served also enables comparing this with the stops sequence in the route
 relation they refer to, adding additional possibilities for validation 
 of
 the data.

 The stops in a timetable sequence should always be a subset of the
 stops in a route relation and appear in the same order.

 Polyglot


 Op di 6 nov. 2018 om 16:07 schreef djakk djakk <
 djakk.dj...@gmail.com>:

> I’ll agree with Leif, having a timetable relation per stop is
> better.

Re: [Talk-es] Estilos de representación cartográfica para la revisión de edificios y direcciones

[Jorge Sanz Sanfructuoso]

El de los tipos de edificios no lo conocía. Muy útil.

Lo único la url que has puesto de la traducción no me funciona. He usado
esta otra
https://josm.openstreetmap.de/josmfile?page=Es:Styles/Coloured_buildings

Gracias por la información


El dom., 4 nov. 2018 a las 18:19, Javier Sánchez Portero (<
javiers...@gmail.com>) escribió:

> Gracias Daniel
> Lo añado a la guía.
>
> El dom., 4 nov. 2018 a las 5:47, dcapillae ()
> escribió:
>
>> Hola.
>>
>> JOSM tiene un par de estilos cartográficos que os pueden resultar de
>> utilidad en el proceso de importación de edificios y direciones del
>> Catastro, tanto para completar tareas como para validarlas: «Coloured
>> Streets» [1] y «Coloured Buildings» [2].
>>
>> «Coloured Streets» es un estilo cartográfico que colorea las calles y las
>> direcciones asociadas a una calle de un mismo color. Si lo activáis en
>> JOSM,
>> podréis comprobar con un simple golpe de vista que direcciones están mal
>> escritas o no corresponden con la calle a la que deberían hacer
>> referencia.
>> Es un error muy común que subamos los cambios sin comprobar si los valores
>> de las etiquetas «addr:street=*» corresponden con el nombre de la calle
>> más
>> cercana, entre otras cosas porque es un engorro tener que comprobar las
>> direcciones una por una. Este estilo cartográfico nos lo pone fácil,
>> haciendo casi imposible que nos equivoquemos, y sin que tengamos que
>> perder
>> tiempo comprobando una por una las direcciones.
>>
>> «Coloured Buildings» es un estilo cartográfico similar, también colorea
>> elementos de OSM en función de sus etiquetas, pero en este caso da color y
>> tipifica los edificios en función del valor de su etiqueta «building=*»,
>> de
>> tal forma que con un simple vistazo podréis conocer qué tipo de edificio
>> estáis editando en JOSM: viviendas unifamiliares, apartamentos, edificios
>> públicos, etc. Con los edificios pasa lo mismo que con las direcciones,
>> también es muy común que se nos pase cambiar la etiqueta
>> «building=residential» que acompaña a muchos edificios importados del
>> Catastro por un valor más preciso. Este estilo cartográfico nos evita
>> tener
>> que seleccionar uno por uno los edificios para saber de qué tipo de
>> edificio
>> se trata, lo que nos ahorra mucho tiempo. Muy útil sobre todo para validar
>> tareas ya completadas.
>>
>> Para activar estos estilos cartográficos os tenéis que dirigir al menú
>> «Ver»
>> y seleccionar las opciones «Estilos de representación cartográfica» y
>> «Preferencias para la presentación del mapa». Buscad «Coloured Streets» y
>> «Coloured Buildings» en la lista de estilos disponibles, y añadirlos a
>> JOSM.
>> Para activarlos o desactivarlos, simplemente tenéis que marcarlos o
>> desmarcarlos del menú de estilos de representación cartográfica, o bien
>> marcarlos o desmarcarlos de la ventana correspondiente que se activa desde
>> el menú «Ventanas».
>>
>> El estilo «Coloured Buildings» estaba escrito originalmente en alemán. Me
>> he
>> descargado el estilo y lo he traducido para que la tipología de edificios
>> aparezca también en español. Tenéis el estilo traducido [3] disponible
>> para
>> su descarga a través del wiki de JOSM. Para usar la traducción en español,
>> os tenéis que descargar el archivo traducido, o bien guardaros la
>> dirección
>> URL de descarga. Os hará falta para añadir el estilo desde la opción
>> «Preferencias para la presentación del mapa», haciendo clic en el icono
>> «+»
>> de la barra lateral derecha.
>>
>> [1] https://josm.openstreetmap.de/wiki/Styles/Coloured_Streets
>> [2] https://josm.openstreetmap.de/wiki/Es%3AStyles/Coloured_buildings
>> [3]
>>
>> https://josm.openstreetmap.de/attachment/wiki/Es%3AStyles/Coloured_buildings/Styles_Coloured_buildings-style.mapcss
>>
>>
>>
>> -
>> Daniel Capilla
>> OSM user: dcapillae
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>>
>> ___
>> 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
>
-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://jorgesanz.es/
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-ca] Exit with name on node *and* destination

[Martijn van Exel]

I did create a MapRoulette challenge to review these named junction nodes for 
the United States just now. See 
https://maproulette.org/mr3/challenge/3253/task/5881462 
. If you find it 
useful I’d be happy to create one for Canada as well. Or show you how you can 
do it yourself.

Martijn

> On Nov 6, 2018, at 11:43 AM, Andrew Lester  wrote:
> 
> I just cleaned up a handful of junctions in the western provinces where refs 
> were in the name tag, destination was in the name on the junction in addition 
> to the link way, etc. Running an Overpass query for all of Canada 
> (http://overpass-turbo.eu/s/DrL) now shows that there are almost 2000 of 
> these in Ontario and Quebec, 2 in Nova Scotia, and 1 in Newfoundland. The 
> last 3 look legitimate, but a quick scan of the ones in Ontario and Quebec 
> shows that most are clear tagging-for-the-renderer. In a few test cases, the 
> destinations are already on the link ways, so there's no need for the 
> destination to be in the name on the junction nodes.
> 
> Does anyone have a good reason for keeping these as they are? My opinion is 
> that these should all have the names removed when it's clearly the 
> destination, and that this destination info should be added to the link way 
> if it isn't already.
> 
> Andrew Lester
> Victoria, BC
> 
> From: "Martijn van Exel" 
> To: "talk-ca" 
> Sent: Tuesday, November 6, 2018 7:56:23 AM
> Subject: Re: [Talk-ca] Exit with name on node *and* destination
> 
> So apparently this is pretty common practice in Quebec. There are 755 
> junction nodes that have name tags. See https://overpass-turbo.eu/s/Dr9. 
> Other provinces don't have nearly that many.  
> 
> The user breakdown for latest edit on those nodes doesn't really surface one 
> mapper who consistently added these tags. See https://overpass-turbo.eu/s/Drf
> 
> I'm inclined to leave it to the local Quebec community to say something more 
> definitive about what, if anything, needs to be done with these name tags... 
> I'm happy to set up a MapRoulette challenge to enable us to systematically 
> look at these nodes..
> 
> Best,
> -- 
>   Martijn van Exel
>   m...@rtijn.org
> 
> On Tue, Nov 6, 2018, at 08:33, Martijn van Exel wrote:
> > Is there an Overpass or other query that could detect all these 
> > situations? I could make a MapRoulette challenge out of them so we can 
> > look at them together and remove the name on nodes where it's not 
> > appropriate / redundant.
> > 
> > I'll ask on IRC as well.. I am not that much of an expert in Overpass.
> > -- 
> >   Martijn van Exel
> >   m...@rtijn.org
> > 
> > On Mon, Nov 5, 2018, at 18:23, Jarek Piórkowski wrote:
> > > Yep, so in this case removing the name and keeping the ref on the
> > > junction node sounds appropriate.
> > > 
> > > While we're at it, the service road
> > > https://www.openstreetmap.org/way/48154169 doesn't seem to show up on
> > > any of the current imagery in iD. Does it still exist?
> > > 
> > > --Jarek
> > > 
> > > On Mon, 5 Nov 2018 at 16:28, Pierre Béland  wrote:
> > > >
> > > > Je disais précédemment
> > > > > Je ne sais pour les autres provinces, mais au Québec les no. de 
> > > > > sorties
> > > > > correspondent aux bornes kilométriques de la route (ici 15 pour km 
> > > > > 15).
> > > > > Il est plus informatif d'afficher le no de sortie (ref=15)
> > > >
> > > >
> > > > Ici c'est sortie 11pour km 11, et non 15 comme j'ai dit précédemment. 
> > > > Sur la carte, la numérotation de la sortie était «noyée» sous le texte.
> > > >
> > > >
> > > > Pierre
> > > >
> > 
> > ___
> > Talk-ca mailing list
> > Talk-ca@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ca
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [Talk-ca] Exit with name on node *and* destination

[Andrew Lester]

I just cleaned up a handful of junctions in the western provinces where refs 
were in the name tag, destination was in the name on the junction in addition 
to the link way, etc. Running an Overpass query for all of Canada 
(http://overpass-turbo.eu/s/DrL) now shows that there are almost 2000 of these 
in Ontario and Quebec, 2 in Nova Scotia, and 1 in Newfoundland. The last 3 look 
legitimate, but a quick scan of the ones in Ontario and Quebec shows that most 
are clear tagging-for-the-renderer. In a few test cases, the destinations are 
already on the link ways, so there's no need for the destination to be in the 
name on the junction nodes. 

Does anyone have a good reason for keeping these as they are? My opinion is 
that these should all have the names removed when it's clearly the destination, 
and that this destination info should be added to the link way if it isn't 
already. 

Andrew Lester 
Victoria, BC 


From: "Martijn van Exel"  
To: "talk-ca"  
Sent: Tuesday, November 6, 2018 7:56:23 AM 
Subject: Re: [Talk-ca] Exit with name on node *and* destination 

So apparently this is pretty common practice in Quebec. There are 755 junction 
nodes that have name tags. See https://overpass-turbo.eu/s/Dr9. Other provinces 
don't have nearly that many. 

The user breakdown for latest edit on those nodes doesn't really surface one 
mapper who consistently added these tags. See https://overpass-turbo.eu/s/Drf 

I'm inclined to leave it to the local Quebec community to say something more 
definitive about what, if anything, needs to be done with these name tags... 
I'm happy to set up a MapRoulette challenge to enable us to systematically look 
at these nodes.. 

Best, 
-- 
Martijn van Exel 
m...@rtijn.org 

On Tue, Nov 6, 2018, at 08:33, Martijn van Exel wrote: 
> Is there an Overpass or other query that could detect all these 
> situations? I could make a MapRoulette challenge out of them so we can 
> look at them together and remove the name on nodes where it's not 
> appropriate / redundant. 
> 
> I'll ask on IRC as well.. I am not that much of an expert in Overpass. 
> -- 
> Martijn van Exel 
> m...@rtijn.org 
> 
> On Mon, Nov 5, 2018, at 18:23, Jarek Piórkowski wrote: 
> > Yep, so in this case removing the name and keeping the ref on the 
> > junction node sounds appropriate. 
> > 
> > While we're at it, the service road 
> > https://www.openstreetmap.org/way/48154169 doesn't seem to show up on 
> > any of the current imagery in iD. Does it still exist? 
> > 
> > --Jarek 
> > 
> > On Mon, 5 Nov 2018 at 16:28, Pierre Béland  wrote: 
> > > 
> > > Je disais précédemment 
> > > > Je ne sais pour les autres provinces, mais au Québec les no. de sorties 
> > > > correspondent aux bornes kilométriques de la route (ici 15 pour km 15). 
> > > > Il est plus informatif d'afficher le no de sortie (ref=15) 
> > > 
> > > 
> > > Ici c'est sortie 11pour km 11, et non 15 comme j'ai dit précédemment. Sur 
> > > la carte, la numérotation de la sortie était «noyée» sous le texte. 
> > > 
> > > 
> > > Pierre 
> > > 
> 
> ___ 
> Talk-ca mailing list 
> Talk-ca@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-ca 

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

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

Yes, very hard to debug and we already established some change every few
months. So after a change from the operator. One traveler will update one
of those schedules, Another may do so for 3 stops down the line, in the
mean time the stops in between and after are not updated yet. A maintenance
nightmare. The way I proposed it, suffers less from that problem. When
timetables change it's usually that trips are added or removed or their
start time changes slightly. The time to get from one stop to the next will
remain constant, most of the time.

Jo

Op di 6 nov. 2018 om 18:40 schreef djakk djakk :

> I don’t get it ...
>
> With my point of view, one route with 15 stops has 15 timetables, each
> timetable describes the arrival time and the departure time of several
> trips at the stop.
>
> There must be the same number of trips along the stops’ timetables.
> (Otherwise this is an other route).
>
> You mean, if somebody messed up and add an extra trip inside a timetable,
> this would be hard to figure ?
>
> Julien “djakk”
>
>
> Le mar. 6 nov. 2018 à 18:30, Jo  a écrit :
>
>> If you have a single one for a stop/route pair, no problem. As soon as
>> you have a few hundred and the information in them starts to conflict with
>> other another timetable relation for the same route it will be extremely
>> hard to figure out where it went wrong.
>>
>> Polyglot
>>
>> Op di 6 nov. 2018 om 17:08 schreef djakk djakk :
>>
>>> In which case a timetable per stop and per route is unmaintable ?
>>>
>>> Julien “djakk”
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a
>>> écrit :
>>>
 I think it is important to have an osm object describing the timetable
 user-oriented for simple editing without any tool.
 The mapper is at a bus stop, takes a picture of the timetable, can
 import it later in osm without the need of any extra tool.
 Validator can be inside a tool.

 Julien « djakk »


 Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
 écrit :

> Almost that ! Sometimes bus stops does not have their official
> timetable, the user have to refer to the closest previous bus stop having
> an official timetable. So this kind of bus stop may not have a timetable 
> in
> osm (except an osm mapper really wants to put it into osm, knowing per
> habits the schedule).
>
>
> Julien « djakk »
>
>
>
> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>
>> You mean per stop/route pair? That's an incredible s amount of
>> relations! It seems to me that it would be a nighmare to try and maintain
>> it that way. At first sight it seems simpler, but with the new proposal i
>> came up with, you can see how the stops of a variation in itinerary tie
>> together.
>>
>> If the vehicle remains in the station longer, the roles could become
>> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
>> the vehicle left at its first stop.
>>
>> Seeing the stops in the timetable relation in the order they are
>> served also enables comparing this with the stops sequence in the route
>> relation they refer to, adding additional possibilities for validation of
>> the data.
>>
>> The stops in a timetable sequence should always be a subset of the
>> stops in a route relation and appear in the same order.
>>
>> Polyglot
>>
>>
>> Op di 6 nov. 2018 om 16:07 schreef djakk djakk > >:
>>
>>> I’ll agree with Leif, having a timetable relation per stop is
>>> better.
>>>
>>>
>>> Yes Leif, there can be a delay expressed in minutes instead of an
>>> arrival-departure pair of time.
>>>
>>> Julien « djakk »
>>>
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a
>>> écrit :
>>>
 In order to reduce the length of the value of the departures= tag,
 should we allow this kind of abstraction level : departures=5:35 ; 
 6:35 ;
 [7-19]:[05;35] ; 20:35 ; 21:35  ?

 Julien « djakk »


 Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
 écrit :

> Martin, maybe locals do know their bus stop timetable, as they
> always use the service they may memorize the schedules ... ?
>
> Julien
>
>
> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>
>> Hi Leif,
>>
>> You made me do it! :-) I sort of stole your proposal and started
>> creating a new one. It differs in rather important ways from your 
>> proposal,
>> so I preferred not modifying your wiki page. I also think it's 
>> important to
>> decouple the (voting for a) full timetable solution from the 
>> solution where
>> tags are added to indicate interval during 'opening_hours' or a 
>> route,
>> which is a lot more likely to be accepted.

Re: [OSM-talk-fr] OsmAnd, un navigateur routier un peu à part

[gnrc]

J'ai la version G-Play limitée à 7 téléchargements et cela fonctionne. Le 
dossier de rangement des cartes est parfois difficile à trouver sur le tel, car 
il peut être dans /android/dat/net.osmand/files ou ailleurs... mais on peux 
aussi personnaliser cet emplacement dans les préférences. 

- Mail original -

De: "Jean-Claude Repetto"  
À: talk-fr@openstreetmap.org 
Envoyé: Mardi 6 Novembre 2018 17:47:59 
Objet: Re: [OSM-talk-fr] OsmAnd, un navigateur routier un peu à part 

Le 06/11/2018 à 16:45, g...@laposte.net a écrit : 
> Bonjour, 
> Savez vous que l'extracteur de carte https://extract.bbbike.org/ permet 
> d'extraire des portion de carte de planet.osm sous différents formats, 
> dont celui de OsmAnd (faire choix format : Android OsmAnd .OBF). 
> Il suffit de mettre ce fichier dans le dossier Osmand de son smartphone 
> pour pouvoir utiliser cette carte hors ligne et sans aucune autre 
> installation 
> 
> Christian G. (gnrc69) 
> 

Bonjour, 

Est-ce que ça marche avec la version "Google Play" d'OsmAnd, ou 
seulement avec la version F-droid ? 

Jean-Claude 


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

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

Re: [Talk-ca] Exit with name on node *and* destination

[OSM Volunteer stevea]

Between "out meta;" and "out meta qt;" there should be a >; but sometimes this 
gets mangled.
Entre "out meta;" et "out meta qt;" il devrait y avoir un >; mais parfois cela 
est mutilé.

So, I'm choosing to share an "OT share link:"
Donc, je choisis de partager un "lien de partage OT:"

http://overpass-turbo.eu/s/DrG

Good luck / bonne chance,
SteveA
California

> As Overpass Turbo allows named area geocoding, try this:
> Comme Overpass Turbo permet le géocodage de zone nommée, essayez ceci:
> 
> [out:xml]
> [timeout:25];
> {{geocodeArea:Quebec}}->.searchArea;
> (
>  way["service"="emergency_access"](area.searchArea);
> );
> out meta;
>> ;
> out meta qt;
> 
> You can modify what is inside the "way" part of the query any way you like.
> Vous pouvez modifier le contenu de la partie "way" de la requête à votre 
> guise.
> 
> SteveA
> California


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

Re: [Talk-ca] Exit with name on node *and* destination

[OSM Volunteer stevea]

On Nov 6, 2018, at 8:08 AM, Pierre Béland  wrote:
> Petit test rapide avec Overpass. J'observe que les clés suivantes sont 
> utilisées
> highway=service
> service=emergency_access
> access=no
> exemple https://www.openstreetmap.org/way/19692719
> 
> La Requête Overpass ci-dessous avec paramètre around, détecte les voies de 
> service à proximité d'autoroutes sans clé  service=emergency_access ou 
> access=no.  Sélection d'un grand bbox requiert long délais d'exécution.  Et 
> d'autres chemins de service se retrouvent dans les résultats, notamment les 
> voies de service pour haltes routières.
> 
> https://www.openstreetmap.org/way/20057142#map=16/44.8089/-73.4450
>  
> Pierre 

As Overpass Turbo allows named area geocoding, try this:
Comme Overpass Turbo permet le géocodage de zone nommée, essayez ceci:

[out:xml]
[timeout:25];
{{geocodeArea:Quebec}}->.searchArea;
(
  way["service"="emergency_access"](area.searchArea);
);
out meta;
>;
out meta qt;

You can modify what is inside the "way" part of the query any way you like.
Vous pouvez modifier le contenu de la partie "way" de la requête à votre guise.

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

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

If you have a single one for a stop/route pair, no problem. As soon as you
have a few hundred and the information in them starts to conflict with
other another timetable relation for the same route it will be extremely
hard to figure out where it went wrong.

Polyglot

Op di 6 nov. 2018 om 17:08 schreef djakk djakk :

> In which case a timetable per stop and per route is unmaintable ?
>
> Julien “djakk”
>
>
> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a écrit :
>
>> I think it is important to have an osm object describing the timetable
>> user-oriented for simple editing without any tool.
>> The mapper is at a bus stop, takes a picture of the timetable, can import
>> it later in osm without the need of any extra tool.
>> Validator can be inside a tool.
>>
>> Julien « djakk »
>>
>>
>> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
>> écrit :
>>
>>> Almost that ! Sometimes bus stops does not have their official
>>> timetable, the user have to refer to the closest previous bus stop having
>>> an official timetable. So this kind of bus stop may not have a timetable in
>>> osm (except an osm mapper really wants to put it into osm, knowing per
>>> habits the schedule).
>>>
>>>
>>> Julien « djakk »
>>>
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>>
 You mean per stop/route pair? That's an incredible s amount of
 relations! It seems to me that it would be a nighmare to try and maintain
 it that way. At first sight it seems simpler, but with the new proposal i
 came up with, you can see how the stops of a variation in itinerary tie
 together.

 If the vehicle remains in the station longer, the roles could become
 00:30-00:35 instead of simply 00:35 for the departure offset to the time
 the vehicle left at its first stop.

 Seeing the stops in the timetable relation in the order they are served
 also enables comparing this with the stops sequence in the route relation
 they refer to, adding additional possibilities for validation of the data.

 The stops in a timetable sequence should always be a subset of the
 stops in a route relation and appear in the same order.

 Polyglot


 Op di 6 nov. 2018 om 16:07 schreef djakk djakk :

> I’ll agree with Leif, having a timetable relation per stop is better.
>
>
> Yes Leif, there can be a delay expressed in minutes instead of an
> arrival-departure pair of time.
>
> Julien « djakk »
>
>
>
> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a
> écrit :
>
>> In order to reduce the length of the value of the departures= tag,
>> should we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>
>> Julien « djakk »
>>
>>
>> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
>> écrit :
>>
>>> Martin, maybe locals do know their bus stop timetable, as they
>>> always use the service they may memorize the schedules ... ?
>>>
>>> Julien
>>>
>>>
>>> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>>>
 Hi Leif,

 You made me do it! :-) I sort of stole your proposal and started
 creating a new one. It differs in rather important ways from your 
 proposal,
 so I preferred not modifying your wiki page. I also think it's 
 important to
 decouple the (voting for a) full timetable solution from the solution 
 where
 tags are added to indicate interval during 'opening_hours' or a route,
 which is a lot more likely to be accepted.

 So here goes:

 https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables

 Please let me know what you think. What I still haven't figured out
 yet is how to differ weekdays that fall in school holiday periods from
 "normal" weekdays. So work in progress.

 Polyglot

 Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com
 >:

> Polyglot:
>
 I think that having a timetable relation for each stop is less
> complicated than having one per route.  There are several advantages 
> to
> this:
> 1) People can easily add a single relation at a time, rather than
> having to do the entire line at one time.  This could make it much 
> easier
> to, for example, have a StreetComplete quest asking "What are the 
> arrival
> times of bus X at this bus stop?"  iD could also have a field at bus 
> stops
> with "arrivals for each parent bus route" that would allow people to
> seamlessly create timetable relations.  It also makes more features
> possible in the future, such as additional tags to each timetable.
> 2) The system is easier for newbies to learn to use.
>

Re: [Talk-us] California is too big ;)

[OSM Volunteer stevea]

Bradley White  wrote:
> I would suggest splitting into North & South along the northern edge
> of the SLO/Kern/San Bernardino county lines as the first step; this
> will at least split the LA and SF Bay areas into separate files, both
> of which I assume account for a significant portion of CA's data.

Exactly what I proposed, but Bradley said it in fewer words (thanks, Bradley), 
something I often find challenging.

The "10 counties + 48 counties" (Southern California and Northern California, 
respectively) method I described is the same thing, it's along northern edges 
of San Luis Obispo, Kern and San Bernardino counties.

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

Re: [Talk-us] California is too big ;)

[Joseph Eisenberg]

Northern and Southern California would work; make the split along the
county boundaries just north of Bakersfield, which conveniently follow one
line of latitude.

It would also be possible to split the State into Northern, Central and
Southern regions, but this would be harder to define.

Joseph

(PS: having separate files for each large island or region in Indonesia
would be very helpful; eg Sumatra, Java, Kalimantan/Borneo, Sulawesi, Bali,
NTT, the Moluccas, and Papua. The French server has individual provinces)
On Tue, Nov 6, 2018 at 5:40 PM Frederik Ramm  wrote:

> Hi,
>
> on the Geofabrik download server, we usually split up countries into
> sub-regions once their single .osm.pbf has gone over a certain size. The
> aim is to make it easy for people to work with data just for their
> region, even on lower-spec hardware where it might be difficult to
> handle huge files.
>
> Every once in a while I check the list of not-yet-split countries and
> split up the largest of them. The current top of the list is
>
> 1. Netherlands
> 2. California
> 3. Indonesia
> 4. Spain
> 5. Czech Republic
> 6. Brazil
> 7. Ontario
> 8. Norway
> 9. Austria
> 10. India
>
> Hence the next country I'll split up is the Netherlands, but after that,
> for the first time ever, a second-level entity (California) will be
> larger than all not-yet-split countries.
>
> So I wonder:
>
> 1. is there already a site where someone interested in only a subset of
> California can download current data and potentially also daily diffs?
>
> 2. is there a demand for this?
>
> 3. what would be a sensible way to split California - in 58 counties, or
> maybe just go with SoCal and NorCal for now?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] California is too big ;)

[OSM Volunteer stevea]

On Nov 6, 2018,at 12:38:05 AM PST, Frederik Ramm  wrote:
> ...on the Geofabrik download server, we usually split up countries into
> sub-regions once their single .osm.pbf has gone over a certain size. The
> aim is to make it easy for people to work with data just for their
> region, even on lower-spec hardware where it might be difficult to
> handle huge files.
> ...but after that,
> for the first time ever, a second-level entity (California) will be
> larger than all not-yet-split countries.
> 
> So I wonder:
> 
> 1. is there already a site where someone interested in only a subset of
> California can download current data and potentially also daily diffs?

Whether you know this or not, your algorithm of "splitting" makes too much 
sense to ignore, especially as there really are those with older hardware and 
"making geographic entities 'bite-sized'" is a technical reality, hence 
necessity.  The data are otherwise simply too large.

> 2. is there a demand for this?

Not by me, but that doesn't mean it doesn't exist, it VERY likely does exist.  
Let's keep OSM "human sized" by making the data that reasonable people and 
reasonable hardware/software toolchains can handle "bite sized," lest we and 
our machines choke on too much data.

> 3. what would be a sensible way to split California - in 58 counties, or
> maybe just go with SoCal and NorCal for now?

I haven't known personally that this "splitting" goes on in OSM (planet.osm 
becoming a smaller .osm or .osm.pbf), but it makes perfect technical sense.

And while I read and understand Vivek Bansal's suggestion about "six 
Californias" and Tod Fitch's "I detest this" (incidentally, I "detest this," 
too), I have suggestion which is likely easier, more "politically simple" and I 
believe is rather geographically elegant.

There is a "straight across" (west to east, "latitudinal") split of California 
(almost) which nicely keeps the major population centers (of Southern and 
Northern California) apart, as well as neatly falls across county lines 
(political boundaries of admin_level=6), as well as is almost a "straight line" 
(geographically, a great circle, because Earth is spheroid).

It works like this:  there are 58 counties in California.  Split these 10 
counties into "Southern California:"

San Diego, Imperial, Orange, Riverside, Los Angeles, Ventura, San Bernardino, 
Santa Barbara, San Luis Obispo and Kern.

And split "the rest" (48 of them) into "Northern California."

Geographically, this is very close to a "straight line" (east west) at about 
latitude 35.7889805 although this wanders very slightly in Sequoia National 
Park (because of a mild survey error 150 years ago near the Kern River, I 
think) and it does take a few minor "jogs" in far eastern California on this 
"line" near Lamont Peak (between two national Wilderness boundaries), another 
"north, then easterly again" jog of about a kilometer near Boulder Peak close 
to United States Highway 395 and finally a similar "north, then easterly again" 
jog of about a mile (~1.6 km) in the Pahrump Valley Wilderness Area very close 
to the Nevada boundary, then easterly a few kilometers to the Nevada State 
Line.  That's it.

Honestly, it sounds more complicated than it is:  most people look at a 
wider-scale map of California's counties and "see" this east-west line rather 
neatly divides California into two, a northern and southern, and simply with 
the designation of "those ten counties" as the method to do so.  It isn't 
"perfectly straight" but it is "perfectly suited" to do this division of 
California, in my opinion.

I hope this helps.  It is one of the few times that living in California has 
intersected with OSM and the talk-us pages where I can say "I think I know what 
I'm talking about here."  Although, I certainly welcome other suggestions:  
these are the "talk" pages, after all!

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

Re: [OSM-talk-fr] OsmAnd, un navigateur routier un peu à part

[Rpnpif]

Le  5 novembre 2018, Christian Rogel a écrit :

> Publication sur osm.fr ? Très volontiers, après correctifs éventuels.
> Justement, j’ai compris, lors de ma recherche, qu’un mise à jour compte comme 
> une carte et est doncsusceptible d’être payante.
> Quelqu’un peut-il confirmer ou infirmer ?
> 
> Apparemment, personne n’a eu l’occasion de se frotter à OsmAndMapCreator qui 
> fabrique des fichiers de cartes en .obm à partir des .osm.
> Serait-ce trop pointu ?
> Un continent inexploré par nos geeks favoris ?

Bonjour,

Je confirme que la contribution payante à OsmAnd Live (mise à jour en
temps quasi réel) est volontaire et facultative si on passe par
F-Droid où rien n'est exigé mais son obole est conseillée. Bien dans la
philosophie du logiciel libre.

Une référence d'OsmAnd : J'ai lu quelque part qu'il est utilisé par
l'UNICEF ou un autre organisme de l'ONU dans certaines de ses missions.
Les humanitaires l'apprécient. Cela démontre son potentiel et sa
souplesse.

J'ai un peu utilisé il y a plusieurs mois OsmAndMapCreator pour déboguer
une carte ou bien pour créer une carte personnelle pour OsmAnd. Je l'ai
aussi utilisé pour des conversions de format.
Ça marche mais c'est rustique et donc à réserver aux geeks.

-- 
Alain Rpnpif

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

Re: [Talk-de] POIs - Details - Gerichtsurteil

[sepp1974]

Simon,

ist alles nachvollziehbar. Es ist sogar davon auszugehen, dass der 
Firmeninhaber der OSM wahrscheinlich gar nicht bewußt kennt, positiv 
überrascht sein wird, dort eine für ihn kostenlose Wegbeschreibung zum 
eigenen Laden zu haben.


Bis der erste Anwalt mit Abmahnung aufgrund fehlender Information nach 
Art. 14 auftaucht.


Selbst wenn nach Art. 6 [1] e od. f eine legitime Möglichkeit gefunden 
werden würde, scheiterts doch ganz sicher an der Verpflichtung zur 
Information nach Art. 14.


Wer will sich denn das antun, wer will sich denn dafür den Hut 
aufsetzen??? Der unbedarfte Mapper der den Namen von seinem 
Lieblingsdöner mappt und deswegen stolz ist wie Bolle?


Wer soll denn diesen Datenbestand pflegen, doch ganz sicher nicht der 
Mapper, der zufällig 3 Jahre später feststellt, dass die namentlich 
genannte Arztpraxis den Inhaber gewechselt hat oder bleibt dafür der 
Mapper verantwortlich, der im Vorbeigehen mal schnell irgendwas 
korrigiert hat, vllt. noch beim Umsteigen an einer Haltestelle in einer 
Gegend, in der er normalerweise nix zu tun hat und sich ein halbes Jahr 
später nichteinmal mehr erinnern kann, dort überhaupt etwas geändert zu 
haben?!


Das ist doch bisher alles Bullshit (tschuldigung) - entweder will ich 
die Daten und finde eine legitime Möglichkeit inkl. der sich daraus 
ergebenden gesetzlichen Verpflichtungen oder ich sage klipp und klar, 
dafür ist's und war's nie gedacht, wir lassen ganz konsequent die Finger 
davon.


Ich warte immer noch auf ganz konkrete Beispiele, wozu personenbezogene 
Daten in dieser Datenbank wichtig wären, das es sich lohnt, eine  
derartigen gesetzlichen Spagat hinzulegen. Für die nachvollziehbarkeit 
historischer Aktivitäten eines Geschäftsbetreibers gibts das 
Handelsregister. Deswegen fällt OSM dort schon mal raus - Fakt!



Gruß Sepp

Am 06.11.2018 15:40 schrieb Simon Poole:

Leute, die DSGVO hat viele Regelungen, gerade wenn es um die Begründung
von legitimen Interessen geht (Art 6.1(f)(, die verlangen das eine
Abwägung der Interessen (die eigenen Interessen gegen die des
Datensubjektes) stattfinden.  Sprich es hängt halt am Schluss von 
diesen

Abwägungen ab ob wir etwas mit Personenbezug in die Daten aufnehmen
sollten oder nicht, z.B. ist es ziemlich klar, dass man bei Artzpraxen
das Interesse an der Auffindbarkeit eines bestimmten Arztes wohl 
anderen
Interessen überwiegt, bei anderen Einrichtungen mag das anders sein. 
Ich

würde aber annehmen, dass bei Geschäften die eine nicht eingetragene,
Fantasie Firma verwenden, ein Interesse am Inhaber durchaus begründbar 
ist.


Simon

 


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


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

Re: [OSM-talk-fr] OsmAnd, un navigateur routier un peu à part

[Jean-Claude Repetto]

Le 06/11/2018 à 16:45, g...@laposte.net a écrit :
> Bonjour,
> Savez vous que l'extracteur de carte https://extract.bbbike.org/ permet
> d'extraire des portion de carte de planet.osm sous différents formats,
> dont celui de OsmAnd (faire choix format : Android OsmAnd .OBF).
> Il suffit de mettre ce fichier dans le dossier Osmand de son smartphone
> pour pouvoir utiliser cette carte hors ligne et sans aucune autre
> installation
> 
> Christian G. (gnrc69)
> 

Bonjour,

Est-ce que ça marche avec la version "Google Play" d'OsmAnd, ou
seulement avec la version F-droid ?

Jean-Claude


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

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[Fernando Trebien]

On Tue, Nov 6, 2018 at 10:52 AM santamariense  wrote:
> O reposicionamento do centroide
> para junto dos logradouros será feito antes de se enviar ao OSM.

Ah ok então. É bastante trabalho, mas de fato é o ideal.

-- 
Fernando Trebien

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

Re: [Talk-it] Import civici Milano - regole di traduzione

[Martin Koppenhoefer]

sent from a phone

> On 6. Nov 2018, at 14:52, Andrea Musuruane  wrote:
> 
>> On Tue, Nov 6, 2018 at 2:46 PM Paolo Monegato <
>> gato.selvad...@gmail.com> wrote:
>> Il 31/10/2018 15:49, Andrea Musuruane ha scritto:
 Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa 
 si fa?
>>> 
>>> Elimini i civici perché non esistono più.
>> Non sarebbe più opportuno anteporre un lifecycle prefix (removed, ad 
>> esempio) per conservare la storia?
>> 
> 
> Show Quoted Content
>> On Tue, Nov 6, 2018 at 2:46 PM Paolo Monegato  
>> wrote:
>> Il 31/10/2018 15:49, Andrea Musuruane ha scritto:
 Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa 
 si fa?
>>> 
>>> Elimini i civici perché non esistono più.
>> Non sarebbe più opportuno anteporre un lifecycle prefix (removed, ad 
>> esempio) per conservare la storia?
>> 
> 
> 
> Perché? Quale utilità avremmo a mantenere un dato che non è più attuale?


metti che la targa del civico ancora c’è. Io ci lascerei il civico finché 
abbiamo verificato che non ce ne è più traccia. Si può aggiungere un tag per 
indicare che il civico è stato soppresso, ma senza alterare i tags addr:*

A noi interessa anche un civico che sembra di esistere ma non è più 
ufficialmente registrato. Se stessi davanti un civico e diresti al tuo amico al 
telefono la posizione non ti interesserebbe se questo civico avesse valore 
legale.

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

Re: [Talk-de] POIs - Details - Gerichtsurteil

[sepp1974]

Das berechtigte Interesse eines Verantwortlichen oder Dritten wird 
schwierig zu begründen. Das setzt ja voraus, dass irgendetwas passiert 
ist, dass ein Interesse als solches im konkreten Fall besteht. (Art. 6 
f) in dem Fall wäre OSM definitiv der falsche Ansprechpartner.


Art. 6 [1] e, 2. Halbsatz: "...ODER in Ausübung öffentlicher Gewalt 
erfolgt, die dem Verantwortlichen übertragen wurde;" (da stehen 2 
Alternativen)


Über die Ausübung der öffentlichen Gewalt, also einem staatlichen 
Auftrag zur Datenverarbeitung hängt die Messlatte meiner Meinung nach 
extrem hoch, um die Erforderlichkeit zur Wahrnehmung von Aufgaben im 
öffentlichen Interesse begründen zu können. (1. Halbsatz) m.M.n. kommt 
man hier lediglich über die gemeinnützigkeit des Vereins rein, wobei ich 
mir nicht vorstellen kann, dass ein Erforderniss zur Verarbeitung 
personenbezogener Daten tatsächlich begründbar ist. Jeder Blick auf die 
OSM-Startseite widerlegt das bereits.


Gruß Sepp

Am 06.11.2018 16:19 schrieb Mark Obrembalski:

Am 06.11.18 um 07:19 schrieb sepp1...@posteo.de:


Yep, der Text zur DS-GVO ist dort ziemlich eindeutig.

OSM kann weder die Grundsätze nach Art. 5 umsetzen, noch bspw. die 
Informationspflichten gem. Art. 13, bzw. 14.
Eine Verarbeitung personenbezogener Daten erfolgt, sobald ich diese 
innerhalb des POI's mit Adresse, Telefonnummer oder weiteren Daten 
verknüpfe.


Die Rechtmäßigkeit einer Verarbeitung wäre überhaupt nur nach Art. 6 
[1] e möglich,


Nein, wesentlich eher nach Buchstabe f. Die Nutzer von OSM-Daten haben
beispielsweise wahrscheinlich ein berechtigtes Interesse daran, sich
informieren zu können, wo sich das Büro eines bestimmten Abgeordneten
(oder die Praxis eines bestimmten Arztes etc.) befindet. Beim Namen
des Inhabers eines Geschäfts, das nicht nach ihm benannt ist, ist ein
solches Interesse schon zweifelhafter.

 wobei hier OSM ersteinmal nachweisen müßte, dass eine
Erforderniss vorliegt, was im Falle des Handelsregisters oder auch der 
Einwohnermeldedatei, welche ja amtlich geführt werden, definitiv nicht 
zu begründen ist. Abgesehen mal davon, liegt die Hürde durch den 
zweiten Halbsatz derart hoch, dass aus meiner Sicht keine Chance 
besteht, dort rechtmäßig in die Erfassung oder Verarbeitung herein zu 
rutschen.


Art. 6 (1) e hat keinen zweiten Halbsatz. Was meinst Du?

Gruß,
Mark

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


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

Re: [Talk-ca] Exit with name on node *and* destination

[Pierre Béland]

Petit test rapide avec Overpass. J'observe que les clés suivantes sont 
utiliséeshighway=serviceservice=emergency_accessaccess=noexemple 
https://www.openstreetmap.org/way/19692719
La Requête Overpass ci-dessous avec paramètre around, détecte les voies de 
service à proximité d'autoroutes sans clé  service=emergency_access ou 
access=no.  Sélection d'un grand bbox requiert long délais d'exécution.  Et 
d'autres chemins de service se retrouvent dans les résultats, notamment les 
voies de service pour haltes routières.
https://www.openstreetmap.org/way/20057142#map=16/44.8089/-73.4450 
Pierre 
 

Le mardi 6 novembre 2018 10 h 33 min 37 s HNE, Martijn van Exel 
 a écrit :  
 
 Is there an Overpass or other query that could detect all these situations? I 
could make a MapRoulette challenge out of them so we can look at them together 
and remove the name on nodes where it's not appropriate / redundant.

I'll ask on IRC as well.. I am not that much of an expert in Overpass.
-- 
  Martijn van Exel
  m...@rtijn.org

On Mon, Nov 5, 2018, at 18:23, Jarek Piórkowski wrote:
> Yep, so in this case removing the name and keeping the ref on the
> junction node sounds appropriate.
> 
> While we're at it, the service road
> https://www.openstreetmap.org/way/48154169 doesn't seem to show up on
> any of the current imagery in iD. Does it still exist?
> 
> --Jarek
> 
> On Mon, 5 Nov 2018 at 16:28, Pierre Béland  wrote:
> >
> > Je disais précédemment
> > > Je ne sais pour les autres provinces, mais au Québec les no. de sorties
> > > correspondent aux bornes kilométriques de la route (ici 15 pour km 15).
> > > Il est plus informatif d'afficher le no de sortie (ref=15)
> >
> >
> > Ici c'est sortie 11pour km 11, et non 15 comme j'ai dit précédemment. Sur 
> > la carte, la numérotation de la sortie était «noyée» sous le texte.
> >
> >
> > Pierre
> >  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Exit with name on node *and* destination

[Martijn van Exel]

So apparently this is pretty common practice in Quebec. There are 755 junction 
nodes that have name tags. See https://overpass-turbo.eu/s/Dr9. Other provinces 
don't have nearly that many.  

The user breakdown for latest edit on those nodes doesn't really surface one 
mapper who consistently added these tags. See https://overpass-turbo.eu/s/Drf

I'm inclined to leave it to the local Quebec community to say something more 
definitive about what, if anything, needs to be done with these name tags... 
I'm happy to set up a MapRoulette challenge to enable us to systematically look 
at these nodes..

Best,
-- 
  Martijn van Exel
  m...@rtijn.org

On Tue, Nov 6, 2018, at 08:33, Martijn van Exel wrote:
> Is there an Overpass or other query that could detect all these 
> situations? I could make a MapRoulette challenge out of them so we can 
> look at them together and remove the name on nodes where it's not 
> appropriate / redundant.
> 
> I'll ask on IRC as well.. I am not that much of an expert in Overpass.
> -- 
>   Martijn van Exel
>   m...@rtijn.org
> 
> On Mon, Nov 5, 2018, at 18:23, Jarek Piórkowski wrote:
> > Yep, so in this case removing the name and keeping the ref on the
> > junction node sounds appropriate.
> > 
> > While we're at it, the service road
> > https://www.openstreetmap.org/way/48154169 doesn't seem to show up on
> > any of the current imagery in iD. Does it still exist?
> > 
> > --Jarek
> > 
> > On Mon, 5 Nov 2018 at 16:28, Pierre Béland  wrote:
> > >
> > > Je disais précédemment
> > > > Je ne sais pour les autres provinces, mais au Québec les no. de sorties
> > > > correspondent aux bornes kilométriques de la route (ici 15 pour km 15).
> > > > Il est plus informatif d'afficher le no de sortie (ref=15)
> > >
> > >
> > > Ici c'est sortie 11pour km 11, et non 15 comme j'ai dit précédemment. Sur 
> > > la carte, la numérotation de la sortie était «noyée» sous le texte.
> > >
> > >
> > > Pierre
> > >
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [OSM-talk-fr] OsmAnd, un navigateur routier un peu à part

[gnrc]

Bonjour, 
Savez vous que l'extracteur de carte https://extract.bbbike.org/ permet 
d'extraire des portion de carte de planet.osm sous différents formats, dont 
celui de OsmAnd (faire choix format : Android OsmAnd .OBF). 
Il suffit de mettre ce fichier dans le dossier Osmand de son smartphone pour 
pouvoir utiliser cette carte hors ligne et sans aucune autre installation 

Christian G. (gnrc69) 

- Mail original -

De: "Stéphane Péneau"  
À: talk-fr@openstreetmap.org 
Envoyé: Mardi 6 Novembre 2018 07:48:33 
Objet: Re: [OSM-talk-fr] OsmAnd, un navigateur routier un peu à part 

Le 05/11/2018 à 22:54, osm.sanspourr...@spamgourmet.com a écrit : 



Le 05/11/2018 à 19:34, Christian Rogel - christian.ro...@club-internet.fr a 
écrit : 



Apparemment, personne n’a eu l’occasion de se frotter à OsmAndMapCreator qui 
fabrique des fichiers de cartes en .obm à partir des .osm.
Serait-ce trop pointu ?
Un continent inexploré par nos geeks favoris ? 


J'ai failli utiliser. Je me suis mis dans un coin et je me suis dit 
qu'installer un Debian sur Termux pouvait être une solution plus radicale. 
Je n'ai pas fait les étapes suivantes. 

Jean-Yvon 



Je l'ai utilisé pour un cas précis il y a quelques mois, j'en parle un peu ici 
: 
http://www.stemani.fr/index.php?post/2018/02/25/Integrer-rapidement-les-parcelles-cadastrales-dans-OsmAnd
 

Stf 

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

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

Re: [Talk-ca] Exit with name on node *and* destination

[Martijn van Exel]

Is there an Overpass or other query that could detect all these situations? I 
could make a MapRoulette challenge out of them so we can look at them together 
and remove the name on nodes where it's not appropriate / redundant.

I'll ask on IRC as well.. I am not that much of an expert in Overpass.
-- 
  Martijn van Exel
  m...@rtijn.org

On Mon, Nov 5, 2018, at 18:23, Jarek Piórkowski wrote:
> Yep, so in this case removing the name and keeping the ref on the
> junction node sounds appropriate.
> 
> While we're at it, the service road
> https://www.openstreetmap.org/way/48154169 doesn't seem to show up on
> any of the current imagery in iD. Does it still exist?
> 
> --Jarek
> 
> On Mon, 5 Nov 2018 at 16:28, Pierre Béland  wrote:
> >
> > Je disais précédemment
> > > Je ne sais pour les autres provinces, mais au Québec les no. de sorties
> > > correspondent aux bornes kilométriques de la route (ici 15 pour km 15).
> > > Il est plus informatif d'afficher le no de sortie (ref=15)
> >
> >
> > Ici c'est sortie 11pour km 11, et non 15 comme j'ai dit précédemment. Sur 
> > la carte, la numérotation de la sortie était «noyée» sous le texte.
> >
> >
> > Pierre
> >

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

Re: [OSM-talk-fr] OsmAnd, un navigateur routier un peu à part

[rainerU]

Am 06.11.18 um 07:48 schrieb Stéphane Péneau:
> Je l'ai utilisé pour un cas précis il y a quelques mois, j'en parle un peu 
> ici :
> http://www.stemani.fr/index.php?post/2018/02/25/Integrer-rapidement-les-parcelles-cadastrales-dans-OsmAnd

J'avais utilisé MapCreator pour générer un fichier OBF contenant des points
d’intérêt. La base était un fichier GPX que j'ai convertit en fichier OSM avec
GpsBabel. Je pense qu'à l’époque on ne pouvait pas importer un fichier GPX dans
Osmand. Pour certains besoins spécifiques cela peut toujours être intéressant.
Par exemple, les liens HTTP dans la description d'un POI ne sont pas cliquables
pour les fichiers GPX importés  mais le sont pour les fichiers au format OBF.


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

Re: [Talk-at] Gesprächskultur (war: Werde Teil der OpenStreeetMap Familie)

[grubernd]

On 06.11.18 15:46, emga wrote:
> Es steht der Mailinglisten Administration frei den „Ban Hammer“ 
herauszuholen.


aber geh, so eine Mailinglist verträgt das leicht, ein Trotzbua mehr 
oder weniger ist da doch egal. sage ich jetzt ganz salopp als 
gewöhnliches Mitglied dieser Ansammlung zivilisierter Mitteleuropäer.



On 06.11.18 16:10, gppes_...@web.de wrote:

Hallo grubernd,

schoen von Dir zu hoeren, schreibst auch mal wieder was im befreundschafteten 
AT-Forum? ;-)


danke! nein, ich mappe lieber - wenn ich Zeit dafür habe - das ist 
generell produktiver. ;-)




Emga, Kopf hoch, Du bist Moderator im Forum, hier kannst Du also ruhig Dampf 
ablassen! ;-)



oder wir lassen alle den Dampf am Steierischen Wald-Multipolygon aus.

*grins*


grüsse,
grubernd

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

Re: [Talk-us] California is too big ;)

[Greg Troxel]

Luis Villa  writes:

>> My guess is the only split that the majority in the state would instantly
>> recognize would be “Northern California” and “Southern California”. However
>> exactly where that split occurs is likely to be contested. :)
>>
>> Were I to hazard a guess, I would start on the coast somewhere around San
>> Luis Obispo
>
> I think Tod is correct here that north/south is the only split most
> Californians would recognize, and that the dividing line is not consistent.
> (You might also get a "Central California" from some folks, but the
> dividing lines there would be similarly fuzzy.) My wife grew up in San Luis
> Obispo, and people from LA tend to say she's from Northern California and
> San Franciscans say she's from Southern California.

I'm someone who has only been to California occasionally, and for me
also the north/south split is the one that seems the most likely for
many to be able to grasp.

I have never heard of "six californias" in any coherent way; it seemed
new on reading.  And I would have little clue about the edges of those
boundaries even seeing the list of names.  So I think that's not a good
idea, because split extracts need to target being understood by
nonlocals.

I would of course recommend listening to locals about exactly shere
between SF and LA the line is, and I would align to counties so that
each county is in north or south, and have the east-west line more or
less try to follow latitude from the breakpoint from the coast.

With a N/S split like we are converging on, most users that are ok with
half will guess right the first time, and people that care about areas
near the border will get it that they are near the border and need both
or the whole thing.

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

Re: [Talk-de] POIs - Details - Gerichtsurteil

[Mark Obrembalski]

Am 06.11.18 um 07:19 schrieb sepp1...@posteo.de:


Yep, der Text zur DS-GVO ist dort ziemlich eindeutig.

OSM kann weder die Grundsätze nach Art. 5 umsetzen, noch bspw. die 
Informationspflichten gem. Art. 13, bzw. 14.
Eine Verarbeitung personenbezogener Daten erfolgt, sobald ich diese 
innerhalb des POI's mit Adresse, Telefonnummer oder weiteren Daten 
verknüpfe.


Die Rechtmäßigkeit einer Verarbeitung wäre überhaupt nur nach Art. 6 [1] 
e möglich,


Nein, wesentlich eher nach Buchstabe f. Die Nutzer von OSM-Daten haben 
beispielsweise wahrscheinlich ein berechtigtes Interesse daran, sich 
informieren zu können, wo sich das Büro eines bestimmten Abgeordneten 
(oder die Praxis eines bestimmten Arztes etc.) befindet. Beim Namen des 
Inhabers eines Geschäfts, das nicht nach ihm benannt ist, ist ein 
solches Interesse schon zweifelhafter.


 wobei hier OSM ersteinmal nachweisen müßte, dass eine
Erforderniss vorliegt, was im Falle des Handelsregisters oder auch der 
Einwohnermeldedatei, welche ja amtlich geführt werden, definitiv nicht 
zu begründen ist. Abgesehen mal davon, liegt die Hürde durch den zweiten 
Halbsatz derart hoch, dass aus meiner Sicht keine Chance besteht, dort 
rechtmäßig in die Erfassung oder Verarbeitung herein zu rutschen.


Art. 6 (1) e hat keinen zweiten Halbsatz. Was meinst Du?

Gruß,
Mark

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

Re: [Talk-at] Gesprächskultur (war: Werde Teil der OpenStreeetMap Familie)

[gppes_osm]

Hallo grubernd,

schoen von Dir zu hoeren, schreibst auch mal wieder was im befreundschafteten 
AT-Forum? ;-)

Johann wird sich ins Faeustchen laecheln, wenn er sich anschaut, was er mit 
seinem gekonnt formulierten Zuendel-Email erreicht hat...

Und zu Volki: Er diskutiert wie bei einem Schachspiel: Elegante 
Diskussionseroeffnung, argumentative Angriffs- und Verteidigungslinien 
aufziehen, diese unter allen Umstaenden halten. Der Blick ist fest auf den 
Monitor (das Schachbrett) gerichtet, das Gegenueber verliert man aus den 
Augen... Ein Konsens oder ein Aufeinanderzugehen ist mit dieser Methode halt 
auch nur schwer moeglich.

Emga, Kopf hoch, Du bist Moderator im Forum, hier kannst Du also ruhig Dampf 
ablassen! ;-)

Lg, Gppes


> Gesendet: Dienstag, 06. November 2018 um 15:24 Uhr
> Von: grubernd 
> An: "OpenStreetMap AT" 
> Betreff: [Talk-at]  Gesprächskultur (war: Werde Teil der OpenStreeetMap 
> Familie)
>
> On 05.11.18 22:13, emga wrote:
> > Und ich steh nicht darauf wenn man aus einer Diskussion dann privat herum 
> > schreibt, entweder öffentlich oder gar nicht.
> > Wenn du mit meiner Arbeit nicht zufrieden bist oder etwas ändern möchtest 
> > kannst du es gerne öffentlich mitteilen bzw. auch selbst mitwirken, wie 
> > schon in meiner Nachricht davor geschrieben. (Ebenso kann es jeder andere 
> > auch)
> 
> 
> ich gebe hiermit öffentlich zu Protokoll, dass ich mit deiner 
> Einstellung zur Kommunikation äusserst unzufrieden bin.
> 
> eine privat geschickte Mail ohne Vorwarnung und Absprache in die 
> Öffentlichkeit zu stellen zeugt von mangelendem Respekt und kompletter 
> Ignoranz in Sachen Gesprächskultur.
> 
> wie und warum so eine Mail privat geschickt wurde ist hierbei vollkommen 
> irrelevant. das ist eine Sache, die der Absender zu entscheiden hat. als 
> Empfänger hast du diese Entscheidung zu respektieren.
> 
> und du handelst als Moderator in einem Forum? in den Foren in denen ich 
> als Moderator aktiv war, war sowas ein lockerer Grund um den Ban-Hammer 
> herauszuholen.
> 
> ich schau da ja seltenst hinein, aber haben sie nicht auch im Forum eine 
> Funktion für private Direktnachrichten? warum wohl?
> 
> 
> grüsse,
> grubernd
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>

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

Re: [Talk-at] Gesprächskultur (war: Werde Teil der OpenStreeetMap Familie)

[emga]

> Am 06.11.2018 um 15:24 schrieb grubernd :
> 
> On 05.11.18 22:13, emga wrote:
>> Und ich steh nicht darauf wenn man aus einer Diskussion dann privat herum 
>> schreibt, entweder öffentlich oder gar nicht.
>> Wenn du mit meiner Arbeit nicht zufrieden bist oder etwas ändern möchtest 
>> kannst du es gerne öffentlich mitteilen bzw. auch selbst mitwirken, wie 
>> schon in meiner Nachricht davor geschrieben. (Ebenso kann es jeder andere 
>> auch)
> 
> 
> ich gebe hiermit öffentlich zu Protokoll, dass ich mit deiner Einstellung zur 
> Kommunikation äusserst unzufrieden bin.

Zu Kenntnis genommen.

> 
> eine privat geschickte Mail ohne Vorwarnung und Absprache in die 
> Öffentlichkeit zu stellen zeugt von mangelendem Respekt und kompletter 
> Ignoranz in Sachen Gesprächskultur.
> 
> wie und warum so eine Mail privat geschickt wurde ist hierbei vollkommen 
> irrelevant. das ist eine Sache, die der Absender zu entscheiden hat. als 
> Empfänger hast du diese Entscheidung zu respektieren.
> 
> und du handelst als Moderator in einem Forum? in den Foren in denen ich als 
> Moderator aktiv war, war sowas ein lockerer Grund um den Ban-Hammer 
> herauszuholen.

Es steht der Mailinglisten Administration frei den „Ban Hammer“ herauszuholen.

> 
> ich schau da ja seltenst hinein, aber haben sie nicht auch im Forum eine 
> Funktion für private Direktnachrichten? warum wohl?
> 
> 
> grüsse,
> grubernd
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at


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

Re: [Talk-us] California is too big ;)

[Bradley White]

> 3. what would be a sensible way to split California - in 58 counties, or
> maybe just go with SoCal and NorCal for now?

I would suggest splitting into North & South along the northern edge
of the SLO/Kern/San Bernardino county lines as the first step; this
will at least split the LA and SF Bay areas into separate files, both
of which I assume account for a significant portion of CA's data.

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

Re: [Talk-de] POIs - Details - Gerichtsurteil

[Simon Poole]

Leute, die DSGVO hat viele Regelungen, gerade wenn es um die Begründung
von legitimen Interessen geht (Art 6.1(f)(, die verlangen das eine
Abwägung der Interessen (die eigenen Interessen gegen die des
Datensubjektes) stattfinden.  Sprich es hängt halt am Schluss von diesen
Abwägungen ab ob wir etwas mit Personenbezug in die Daten aufnehmen
sollten oder nicht, z.B. ist es ziemlich klar, dass man bei Artzpraxen
das Interesse an der Auffindbarkeit eines bestimmten Arztes wohl anderen
Interessen überwiegt, bei anderen Einrichtungen mag das anders sein. Ich
würde aber annehmen, dass bei Geschäften die eine nicht eingetragene,
Fantasie Firma verwenden, ein Interesse am Inhaber durchaus begründbar ist.

Simon

 



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

Re: [Talk-us] California is too big :)

[Brian M Hamlin]

Hi OSM US List -

  California native and current resident here --
while implementing California urban planning analysis a few years ago, 
we used a grouping based on the transportation governance here. 
The grouping is shown graphically in a blog post [0]
 
  CA Landuse is governed at the county level, with associations of counties
for regional planning (water, public transportation). So the groups are
by county, without a doubt. 
 
  Intuitively, large metro areas are one group each - Sacramento area, 
San Francisco Bay Area, Los Angeles.   San Diego county stands alone. 
The remainder of the state has so few people, that very large areas are
just one group each - Central Coast, Sierras, Northern California (vast). 
 
   This might be a guide for some future OSM extracts.. 
County details on request. 
 
[0] http://blog.light42.com/wordpress/?p=1439

--
Brian M Hamlin
blog.light42.com

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

Re: [Talk-cz] Nefunkční taginfo

[Tom Ka]

Tak snad jo, prosim o otestovani jestli jsem na neco nezapomel.

Diky
út 6. 11. 2018 v 14:04 odesílatel Tom Ka  napsal:
>
> út 6. 11. 2018 v 6:32 odesílatel Marián Kyral  napsal:
> > Tak hlásím, že opraveno, ale bude nějakou pár hodin trvat, než se
> > zneplatní keše a změna se dostane opravdu všude.
> >
> > Tak taginfo teď vede na openstreetmap.cz,  což si nejsem jist, zda je dobře.
>
> S tim bych uz si mel byt schopen poradit, mrknu na to.
>
> Bye a diky.

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

[Talk-at] Gesprächskultur (war: Werde Teil der OpenStreeetMap Familie)

[grubernd]

On 05.11.18 22:13, emga wrote:

Und ich steh nicht darauf wenn man aus einer Diskussion dann privat herum 
schreibt, entweder öffentlich oder gar nicht.
Wenn du mit meiner Arbeit nicht zufrieden bist oder etwas ändern möchtest 
kannst du es gerne öffentlich mitteilen bzw. auch selbst mitwirken, wie schon 
in meiner Nachricht davor geschrieben. (Ebenso kann es jeder andere auch)



ich gebe hiermit öffentlich zu Protokoll, dass ich mit deiner 
Einstellung zur Kommunikation äusserst unzufrieden bin.


eine privat geschickte Mail ohne Vorwarnung und Absprache in die 
Öffentlichkeit zu stellen zeugt von mangelendem Respekt und kompletter 
Ignoranz in Sachen Gesprächskultur.


wie und warum so eine Mail privat geschickt wurde ist hierbei vollkommen 
irrelevant. das ist eine Sache, die der Absender zu entscheiden hat. als 
Empfänger hast du diese Entscheidung zu respektieren.


und du handelst als Moderator in einem Forum? in den Foren in denen ich 
als Moderator aktiv war, war sowas ein lockerer Grund um den Ban-Hammer 
herauszuholen.


ich schau da ja seltenst hinein, aber haben sie nicht auch im Forum eine 
Funktion für private Direktnachrichten? warum wohl?



grüsse,
grubernd

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

Re: [Talk-at] Fwd: Werde Teil der OpenStreeetMap Familie

[Friedrich Volkmann]

On 06.11.2018 14:32, emga wrote:

Am 06.11.2018 um 14:22 schrieb Friedrich Volkmann :

Wie auch immer, dir ist mittlerweile hoffentlich klar, dass ein allgemeiner 
Informationspost nicht ins Österreich-Forum hineingehört. Sonst könnte der nächste einen 
Beitrag "rettet die Wale" hineinstellen, weil das ja ebenso ein allgemeiner 
Informationspost ist und noch dazu besonders wichtig.


Mach dich nicht lächerlich…du hast genau Verstanden um was es geht.


Ich schon. Und das Sichlächerlichmachen ist genau der Grund, warum man kein 
EOD verlautbaren sollte, wenn man anschließend selber nicht widerstehen 
kann, noch einen Beitrag anzuhängen. ;-)


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

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

Re: [Talk-us] California is too big ;)

[Luis Villa]

On Tue, Nov 6, 2018 at 5:59 AM Tod Fitch  wrote:

>
> For background, I a 40 year resident of California and have lived, worked
> and/or performed volunteer work in five of the “six Californias”. At
> present I live in Orange County (part of the Six California’s “South
> California” and perform volunteer work, including map generation, for an
> area where the boundary between Ventura County and Kern County (“West
> California” and “Central California”) runs through the middle of the
> parking area.
>
> My guess is the only split that the majority in the state would instantly
> recognize would be “Northern California” and “Southern California”. However
> exactly where that split occurs is likely to be contested. :)
>
> Were I to hazard a guess, I would start on the coast somewhere around San
> Luis Obispo
>

I think Tod is correct here that north/south is the only split most
Californians would recognize, and that the dividing line is not consistent.
(You might also get a "Central California" from some folks, but the
dividing lines there would be similarly fuzzy.) My wife grew up in San Luis
Obispo, and people from LA tend to say she's from Northern California and
San Franciscans say she's from Southern California.

I realize this doesn't help much, just pointing out that you're probably
going to end up drawing some arbitrary lines however you slice it. Maybe
want you want is some kind of clustering based on number of nodes?

(As a further data point on the Six Californias plan, note that it is just
one of many plans introduced even this decade
.
So not useful.)

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

Re: [Talk-es] Fwd: Reconocimiento IGN en OSM

[Miguel Sevilla-Callejo]

Hola a todos de nuevo,

Escribo para retomar el tema del reconocimiento de los datos del IGN en la
página de OSM.

Os comento que el tema centró buena parte de la reunión que tuvimos el
pasado día 20 de octubre en la Geocamp [0] y a ver si vamos avanzando a
pues falta de haber enviado un resumen de lo que se trató en esa reunión y
ya que han salido otros temas (como el de la de la normalización de las
carreteras).

La cuestión es que hemos de consensuar una opinión y una respuesta al IGN
sobre el problema. En la reunión de la Geocamp, los asistentes (Santiago
Crespo, Oscar Zorrilla, Yopaseopor, Lanxana, Jorge Sánz / Sanchi y yo)
estuvimos debatiendo sobre la cuestión y nos pareció correcta la propuesta
de Santiago y que está enlazada en este mismo hilo [2]

Estamos esperando comentarios, sugereancias y opiniones al respecto para en
breve, de aquí a fin de mes, volver a reunirnos con la gente del IGN y
exponerles nuestra postura.

Os rogaría dierais vuestra opinión al respecto para poder ir con suficiente
respaldo a esa reunión.

Un saludo

[0] Hilo de la lista informando del asunto:
https://lists.openstreetmap.org/pipermail/talk-es/2018-October/016327.html
[1] Por si acaso, es este mensaje:
https://lists.openstreetmap.org/pipermail/talk-es/2018-October/016345.html

--
*Miguel Sevilla-Callejo*
Doctor en Geografía


On Fri, 19 Oct 2018 at 23:44, Santiago Crespo 
wrote:

> Hola,
>
> Voy a intentar responder a las cuestiones que plantea Antonio en el PDF.
> Ojo, hablo en plural pero es mi opinión. Si alguien no está de acuerdo
> con algo, que por favor lo comente e intentamos consensuar una respuesta
> entre todos.
>
> 1) y 8) Hemos adaptado las fórmulas de reconocimiento según lo que nos
> piden.
>
> 2) y 3) Nosotros también estamos muy interesados en dar el
> reconocimiento apropiado al IGN y al SCNE.
>
> 4) Estamos de acuerdo, vamos a movilizarnos de nuevo para conseguir que
> la atribución a todos los grandes contribuidores esté a un click.
>
> 5) 6) y 7) Son motivos históricos. Parece ser que hace años la OSMF
> ofreció a varias organizaciones aparecer en la página de copyright a
> cambio de poder usar sus datos, pero es algo que no escala y que no
> volverían a hacer. Entendemos que esto es un agravio comparativo y vamos
> a hacer todo lo posible para solucionarlo.
>
> Saludos,
> Santiago Crespo
>
>
> On 10/19/18 11:27 AM, Miguel Sevilla-Callejo wrote:
> > Hola,
> >
> > El asunto que trato en este correo es de GRAN RELEVANCIA:
> >
> > Os remito más abajo (leer desde los correos de abajo hacia arriba) el
> > intercambio de correos que he tenido estos días con el subdirector
> > adjunto con Antonio F. Rodríguez Pascual, Subdirector adjunto del Centro
> > Nacional de Información Geográfica.
> >
> > Desde esta institución vuelven a llamarnos la atención con la atribución
> > de los datos en el proyecto.
> >
> > Como podréis leer ya le he remitido a alguna de nuestras discusiones en
> > el pasado pero quiero recordar que los últimos pasos que se dieron, la
> > menos en el tema de la aparición del IGN en la página de Copyright de
> > OSM se había llevado a la gente de la FOSM pero no encuentro qué se dijo
> > finalmente. Es más, pensé que desde el IGN esto ya estaba zanjado.
> >
> > Todo el material de lo que ya hemos discutido y lo que se había acordado
> > al respecto más vuestras opiniones será de gran ayuda para reestablecer
> > relaciones con el IGN y plantearles soluciones a sus inquietudes.
> >
> > Mañana en la reunión de la Geocamp sacaré el tema y reflexionaremos al
> > respecto los que allí estemos. En cuento sepa la hora para conexión
> > remota os pongo al corriente (espero enviar correo al respecto).
> >
> > Un saludo
> >
> > --
> > *Miguel Sevilla-Callejo*
> > Doctor en Geografía
> >
> >
> > -- Forwarded message -
> > From: *Rodríguez Pascual Antonio Federico*  > >
> > Date: Fri, 19 Oct 2018 at 10:00
> > Subject: RE: Reconocimiento IGN en OSM
> > To: Miguel Sevilla-Callejo  > >
> >
> >
> > Gracias por todo Miguel.
> > Claro que puedes reenviar este mensaje a quien quieras.
> > Entiendo que el IGN no ha contribuido tanto a OSM como otros, ok.
> > Pero preferiria que todos los reconocimientos se hicieran en la mima
> > pagina e independientemente, se describiese cuantitativamente la
> > aportacion con alguna metrica: por ejemplo muy poco , poco, media, alta
> > y muy alta, distinguiendo datos aportados (hay cierta obligacion) de
> > esfuerzo en horas perona (se teconoce por agradecimiento).
> > Un abrazo.
> > Antonio
> >
> >
> > Enviado desde mi dispositivo Samsung
> >
> >
> >  Mensaje original 
> > De: Miguel Sevilla-Callejo  > >
> > Fecha: 19/10/18 9:46 (GMT+01:00)
> > Para: Rodríguez Pascual Antonio Federico  > >
> > Asunto: Re: Reconocimiento IGN en OSM
> >
> > Hola Antonio,
> >
> > Voy a llevar este tema a la reunión de la Geocamp y lo voy a 

Re: [Talk-it] Import civici Milano - regole di traduzione

[Paolo Monegato]

Il 06/11/2018 14:52, Andrea Musuruane ha scritto:


On Tue, Nov 6, 2018 at 2:46 PM Paolo Monegato 
mailto:gato.selvad...@gmail.com>> wrote:


Il 31/10/2018 15:49, Andrea Musuruane ha scritto:


Se incontriamo con la conflation dei civici già mappati ma
soppressi, cosa si fa?


Elimini i civici perché non esistono più.


Non sarebbe più opportuno anteporre un lifecycle prefix (removed,
ad esempio) per conservare la storia?

Perché? Quale utilità avremmo a mantenere un dato che non è più attuale?


Metti che il civico è soppresso perché han murato l'ingresso. Avere un 
removed:addr:etc ti fa capire cosa c'era in precedenza. Idem se è stato 
soppresso perché han demolito lo stabile (removed:building)...


ciao
Paolo M

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

Re: [Talk-us] California is too big ;)

[Tod Fitch]

> On Nov 6, 2018, at 5:23 AM, Frederik Ramm  wrote:
> 
> Tod,
> 
> generally, the Geofabrik OSM PBF extracts are available across the size
> spectrum from continent to smallest extract, so the California OSM PBF
> extract will not go away (sorry if I was unclear about that).
> 
> But my assumption was that there might be a need for smaller files
> because the whole-California file has meanwhile reached a size where it
> takes a while to process.

I understand the issue and appreciate the proactive stance.

> 
> The only thing that *does* go away when I split something in smaller
> files is the free shape downloads - these are only available for the
> "leaves" of the tree, i.e. the smallest regional units.
> 
> On 06.11.2018 13:58, Tod Fitch wrote:
>> In any case, I assume a good description of the extract boundaries will
>> be provided
> 
> Heh, I had hoped that by asking here, I'll be able to find a
> self-explaining split where everyone knows immediately from the name
> what's in it. Apparently not so easy ;)
> 

For background, I a 40 year resident of California and have lived, worked 
and/or performed volunteer work in five of the “six Californias”. At present I 
live in Orange County (part of the Six California’s “South California” and 
perform volunteer work, including map generation, for an area where the 
boundary between Ventura County and Kern County (“West California” and “Central 
California”) runs through the middle of the parking area.

My guess is the only split that the majority in the state would instantly 
recognize would be “Northern California” and “Southern California”. However 
exactly where that split occurs is likely to be contested. :)

Were I to hazard a guess, I would start on the coast somewhere around San Luis 
Obispo and end up on the Nevada border far enough north to include the Mammoth 
Mountain and June Lake resort areas in Southern California. I haven’t a clue 
where the line ought to go through the San Joaquin Valley though.

Cheers!






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[Peter Krauss]

Oi gente, respondendo inline ao @santamariense  e já
imaginando como seria consolidar a atual discussão no Talk da Wiki,

https://wiki.openstreetmap.org/wiki/Talk:Curitiba/Importa%C3%A7%C3%A3o_IPPUC

On Tue, Nov 6, 2018 at 10:52 AM santamariense  wrote:

> Obrigado pessoal pelo feedback. Fiz na calculadora de campo mesmo a
> formatação dos nomes e números, quanto a isso tá suave.
>
>
Sugestão: se achar um tempo comenta na Wiki o que seria essa "calculadora
de campo".


> Trebien, talvez não tinha explicado direito, mas de qualquer maneira
> acho que o Sérgio já deixou claro. O reposicionamento do centroide
> para junto dos logradouros será feito antes de se enviar ao OSM.
>

Joia, acho que todos concordam que é o procedimento correto.


>
> Paulo, não me parece fácil de implementar. Mas vou tentar. Se não
> conseguir vai ser manualmente mesmo.
>

Como comentei posso ajudar, mas *precisa ser algo certo*, pois vai tomar
nosso tempo (chuto meia hora de videoconferência inicial e final e duas
horas minhas como voluntário pilotando o PostGIS).
... O importante não é apenas ficar bonitinho (eu pessoalmente acho bem
mais bonitinho e funcional os pontos próximos da rua e não perdidos no meio
do lote), mas criar um exemplo de boas práticas e deixar todos os recursos
documentados e disponíveis para que futuras importações possam ser melhor
automatizadas.
O algoritmo que uso é em linhas gerais como o Paulo descreve, se baseia em
*ST_Centroid(ST_Intersection(lote,ST_Buffer(way,x)))* depois de um esquema
de ajuste desse *x*. Também tem condições do tipo usar centroide se o lote
possuir área inferior a 20m2, e usar *ST_PointOnSurface()* se o centroide
"vazar" (ex. lote em forma de U).



>
> Uma questão que me foi sugerida fora da discussão aqui da lista é de
> não usar source=Prefeitura em todos os pontos gerados, mas sim apenas
> nas changesets. Algum forte motivo para manter a source em todos os
> pontos?
>

Eu não sou expert, mas pelo que entendi o ChangeSet ajuda a
documentar/rastrear a fonte (source), portanto basta garantir isso.
Isso é bom, é uma maneira de normalizar os dados, não ficar um monte de
redundância no OSM...

Aí, se de fato há como resgatar a "informação inicial" rastreando-a pelo
ChangeSet... Bom, ideal que essa informação inicial seja mais rica, menos
vaga que "Prefeitura"...
Acho que podemos até criar uma convenção para documentar e rotular os
*lotes-de-dados* de *sources* do Brasil (a sua Wiki

já está ótima  como documentação). Acho que cabe usar como parte do rótulo
a data de criação dos dados (quando a Prefeitura os atualizou),
seria algo como "*Prefeitura:IPPUC:2018-07*".



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

Re: [Talk-it] Import civici Milano - regole di traduzione

[Andrea Musuruane]

Ciao,

On Tue, Nov 6, 2018 at 2:46 PM Paolo Monegato 
wrote:

> Il 31/10/2018 15:49, Andrea Musuruane ha scritto:
>
> Se incontriamo con la conflation dei civici già mappati ma soppressi, cosa
>> si fa?
>>
>
> Elimini i civici perché non esistono più.
>
> Non sarebbe più opportuno anteporre un lifecycle prefix (removed, ad
> esempio) per conservare la storia?
>
Perché? Quale utilità avremmo a mantenere un dato che non è più attuale?

Ciao,

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

Re: [Talk-it] Import civici Milano - regole di traduzione

[Paolo Monegato]

Il 31/10/2018 15:49, Andrea Musuruane ha scritto:


Se incontriamo con la conflation dei civici già mappati ma
soppressi, cosa si fa?


Elimini i civici perché non esistono più.


Non sarebbe più opportuno anteporre un lifecycle prefix (removed, ad 
esempio) per conservare la storia?


ciao
Paolo M

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

Re: [Talk-at] Fwd: Werde Teil der OpenStreeetMap Familie

[emga]

> Am 06.11.2018 um 14:22 schrieb Friedrich Volkmann :
> 
> 
> Wie auch immer, dir ist mittlerweile hoffentlich klar, dass ein allgemeiner 
> Informationspost nicht ins Österreich-Forum hineingehört. Sonst könnte der 
> nächste einen Beitrag "rettet die Wale" hineinstellen, weil das ja ebenso ein 
> allgemeiner Informationspost ist und noch dazu besonders wichtig.

Mach dich nicht lächerlich…du hast genau Verstanden um was es geht.

> -- 
> Friedrich K. Volkmann   http://www.volki.at/
> Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at


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

[Talk-br] OSM Foundation e comunidade latina

[Wille]

A próxima eleição para o board da OSM Foundation será em 15 de Dezembro. 
Quem deseja participar da votação, deve se registrar como membro da 
Fundação até o dia 15 de novembro: https://join.osmfoundation.org/



Consegui articular uma conversa entre membros do atual board da OSM 
Foundation e a comunidade OSM Latam. O chat será realizado na próxima 
terça, às 13:00, de Brasília, no canal telegram OpenStreetMap Latam - 
https://t.me/OSMLatam  . Será uma 
oportunidade de expressarmos nossa opinião em relação ao OpenStreetMap e 
à OSM Foundation e conhecer melhor a visão do atual board.


--
Wille Marcel
http://wille.blog.br/

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

Re: [Talk-us] California is too big ;)

[Frederik Ramm]

Tod,

generally, the Geofabrik OSM PBF extracts are available across the size
spectrum from continent to smallest extract, so the California OSM PBF
extract will not go away (sorry if I was unclear about that).

But my assumption was that there might be a need for smaller files
because the whole-California file has meanwhile reached a size where it
takes a while to process.

The only thing that *does* go away when I split something in smaller
files is the free shape downloads - these are only available for the
"leaves" of the tree, i.e. the smallest regional units.

On 06.11.2018 13:58, Tod Fitch wrote:
> In any case, I assume a good description of the extract boundaries will
> be provided

Heh, I had hoped that by asking here, I'll be able to find a
self-explaining split where everyone knows immediately from the name
what's in it. Apparently not so easy ;)

Best
Frederik

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



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

[talk-latam] OSM Foundation y comunidad Latam

[Wille]

La próxima elección de la OSM Foundation será en 15 de Deciembre. 
Aquellos que deseen votar, deben registrarse como miembro de la OSM 
Foundation hasta el 15 Noviembre: https://join.osmfoundation.org/



En el próximo Martes, 13 de Noviembre, a las 12:00 (BsAs/Santiago) / 
13:00 (Brasília), tendremos un chat entre miembros del board de la OSM 
Foundation y la comunidad Latam. La charla será acá en el canal telegram 
OpenStreetMap Latam (https://t.me/OSMLatam). Así tendremos la 
posibilidad de expresar nuestra opinión en relación a la OSMF y a todo 
el proyecto, y conocer mejor el trabajo y la visión del actual board.



--
Wille Marcel
http://wille.blog.br/

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

Re: [Talk-cz] Nefunkční taginfo

[Tom Ka]

út 6. 11. 2018 v 6:32 odesílatel Marián Kyral  napsal:
> Tak hlásím, že opraveno, ale bude nějakou pár hodin trvat, než se
> zneplatní keše a změna se dostane opravdu všude.
>
> Tak taginfo teď vede na openstreetmap.cz,  což si nejsem jist, zda je dobře.

S tim bych uz si mel byt schopen poradit, mrknu na to.

Bye a diky.

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

Re: [OSM-talk] How to get an overview of multiple gpx on OSM map?

[Dave F]

Hi
There are lots of sites giving advice on GPS usage, but one I tip I 
found useful was always keep a charged battery in your unit. Even though 
it's switched off it still receives the occasional signal from 
satellites to keep track of their locations. if it loses coordination 
with them it can take ages to relocate.


Cheers
DaveF

On 06/11/2018 11:37, Oleksiy Muzalyev wrote:

Thank you, dikkeknodel.

I also received an email message with an advice to acquire Garmin 
eTrex.  I've ordered the Garmin eTrex 35 Touch with the pre-installed 
«TopoActive» Karte Europa, which is based on the OSM data, as I 
understood:

https://www.brack.ch/garmin-hand-gps-etrex-touch-370929

It supports the EGNOS, European Geostationary Navigation Overlay 
Service, which is supposed to correct the GPS signal. I have no idea 
how it works in reality. It also has got the GPS and barometric 
altimeters.


Best regards,
Oleksiy



On 05.11.18 19:59, _ dikkeknodel wrote:


Hi all,

Thanks for all the great advice. I’ve looked into uMap and it does 
the job perfectly. With all the gpx of over a year of hiking imported 
it still runs smoothly.


I would like to prevent running into performance issues later though. 
Does anybody know if it is wise to add ‘simplified’ versions of the 
gpx to uMap instead of the original recordings with 1 s resolution?


Since the published data is public, I just have to take into account 
not to import gpx which start from my home since I value my ‘sort of 
anonymity’.


*@Oleksiy*

To answer Oleksiy’s question, I record with OSMand on a Moto G4 
smartphone, that works like a charm. Off course there is fluctuation 
due to accuracy errors, I guess 10-15 m is achievable most of the 
time, but close to near vertical mountains it becomes much worse.


It however does never happen that I miss long stretches of data 
(except for tunnels ). I did have that problem in the past, when 
<15% battery charge and Android automatically started the battery 
saving mode. That just turned of the gps antenna whenever the screen 
was off. So now I have set battery saving mode to off.


Also OSMand does not drain the battery much. Usually I do take a lot 
of notes which OSMand attaches to the gpx and loads perfectly into 
JOSM. Recently I also used the voice recorder of OSMand, which really 
speeds up the note taking while on the go in comparison to typing. 
These also load into JOSM via the gpx, but some fiddling with the 
location of the audio is required. Taking notes on the phone does 
have an effect on the battery life off course. A 20 km hike in the 
mountains easily takes 6-8h, which my phone reaches most of the time 
on one charge in flight mode. I do have a power-bank as back-up, and 
for multi-day hikes though.


Altitude measurements have always been a bit tricky with OSMand. I 
guess the raw elevation data from gps fluctuates quite a lot, and the 
data processing did not do a good job filtering errors from actual 
elevation change. After a hike with 1000m elevation gain according to 
the map, OSMand often showed I did 5000m... The graph of the track 
you can generate in OSMand also showed a lot of spikes with instant 
ascents of >200m. Recently that seems to have changed and the 
measurements seem to better represent the actual situation.


Hope this helps you with you work OSM workflow!

Cheers,

dikkeknodel

*Van: *Oleksiy Muzalyev 
*Verzonden: *zaterdag 3 november 2018 18:51
*Onderwerp: *Re: [OSM-talk] How to get an overview of multiple gpx on 
OSM map?


Hi _dikkeknodel,

I have a question - how do you record a GPX trace during 20 km walk? 
It should be about 4 hours.


I also record GPS traces but usually for 15-20 minutes. I use a phone 
with the OSMTracker app for Android with mixed results. Sometimes it 
records a path well, sometimes it turns the second part of the walk 
into a long direct line. Such a trace I usually discard.


Besides it empties the phone battery rather quickly. I usually take a 
power-bank with me, but still it is not a good solution to get a 
phone battery empty in mountains.


I am thinking of getting a dedicated device which can record the GPX 
files, on the OSM map, and also measure and altitude more or less 
correctly. The question is - what device, what model.


Best regards,
Oleksiy


On 03.11.18 16:09, _ dikkeknodel wrote:

Hi all,

Ever since I moved to Switzerland over a year ago I’ve been both
hiking in the mountains and updating OSM details a lot. Since I
hike at least 20 km every weekend, it must have totaled to about
1200 km by now all across the country. I would love to get an
overview of where I have been so far.

Since I’ve got a GPX file of almost every hike, the data is
there. I am now looking for a nice graphical way to plot all of
these files at once on a nice OSM map, OpenTopoMap as a base
layer would be great.

I’ve been searching for a while how to arrange this (without much
  

Re: [Talk-us] California is too big ;)

[Tod Fitch]

I detested the “Six Californias” when it was being proposed as a ballot 
measure. Perhaps that is flavoring my response, but at one time or another I’ve 
generated topo maps for areas that lie within four of those six divisions so it 
would be a bit of a hassle for me to have that.

If a split need be made I would prefer a single one which logically would be on 
a north-south basis, probably based on the number of OSM objects but following 
some county boundaries that can be listed in the description.

In any case, I assume a good description of the extract boundaries will be 
provided (unlike Maps.me and now Osmand where the names of the sub-state areas 
are all that is provided and it is not clear to me the exact extent of coverage 
is for any given map download).

At present there is a us-west extract covering basically the Rocky Mountain 
states and west. Last I checked it was a bit over twice the size of California 
alone. Along that same line, would the current extract for California continue 
in addition to the sub-state extracts? If so, then I will withdraw my opinion 
on where the state extracts should be split as I can continue, at least for the 
while, with using the full state data.

Thank you for your attention to this and for your organization making these 
extracts available!

Cheers!
Tod

> On Nov 6, 2018, at 2:53 AM, Vivek Bansal <3viv...@gmail.com> wrote:
> 
> Hi Frederik,
> 
> Yes California is too big!  We also like the attention!
> 
> 1.  Since the demise of metrozen extracts, I don't know of a good site 
> outside of Geofabrik to get regulary updated OSM extracts of California.  
> There is https://www.interline.io/osm/extracts/ 
>  but it is a similar business model 
> to the Geofabrik Downloads.
> 
> 2.  I would certainly love smaller more regularly updated extracts!  I'm not 
> sure how much my team would pay for it though.  We would use them to power 
> our Opentripplanner instance.  We would want the whole San Francisco Bay Area 
> in one extract.
> 
> 3.  I think the most common analysis patterns rely on regions greater than 
> each county, but smaller than just NorCal and SoCal.  The 6 californias here: 
> https://en.wikipedia.org/wiki/Six_Californias 
> 
> is pretty close to what I would suggest (except i'd have the Bay Area 9 
> county region to be one group, perhaps the 7th California?).  I don't know of 
> any spatial files with this breakdown.
> 
> Sincerely,
> Vivek
> 
> On Tue, Nov 6, 2018 at 12:40 AM Frederik Ramm  > wrote:
> Hi,
> 
> on the Geofabrik download server, we usually split up countries into
> sub-regions once their single .osm.pbf has gone over a certain size. The
> aim is to make it easy for people to work with data just for their
> region, even on lower-spec hardware where it might be difficult to
> handle huge files.
> 
> Every once in a while I check the list of not-yet-split countries and
> split up the largest of them. The current top of the list is
> 
> 1. Netherlands
> 2. California
> 3. Indonesia
> 4. Spain
> 5. Czech Republic
> 6. Brazil
> 7. Ontario
> 8. Norway
> 9. Austria
> 10. India
> 
> Hence the next country I'll split up is the Netherlands, but after that,
> for the first time ever, a second-level entity (California) will be
> larger than all not-yet-split countries.
> 
> So I wonder:
> 
> 1. is there already a site where someone interested in only a subset of
> California can download current data and potentially also daily diffs?
> 
> 2. is there a demand for this?
> 
> 3. what would be a sensible way to split California - in 58 counties, or
> maybe just go with SoCal and NorCal for now?
> 
> Bye
> Frederik
> 
> --
> Frederik Ramm  ##  eMail frede...@remote.org   ## 
>  N49°00'09" E008°23'33"
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us 
> 
> On Tue, Nov 6, 2018 at 12:40 AM Frederik Ramm  > wrote:
> Hi,
> 
> on the Geofabrik download server, we usually split up countries into
> sub-regions once their single .osm.pbf has gone over a certain size. The
> aim is to make it easy for people to work with data just for their
> region, even on lower-spec hardware where it might be difficult to
> handle huge files.
> 
> Every once in a while I check the list of not-yet-split countries and
> split up the largest of them. The current top of the list is
> 
> 1. Netherlands
> 2. California
> 3. Indonesia
> 4. Spain
> 5. Czech Republic
> 6. Brazil
> 7. Ontario
> 8. Norway
> 9. Austria
> 10. India
> 
> Hence the next country I'll split up is the Netherlands, but after that,
> for the first time ever, a second-level entity (California) will be
> larger than all not-yet-split countries.
> 
> So I 

Re: [Talk-us] California is too big ;)

[Frederik Ramm]

Hi,

On 06.11.2018 11:53, Vivek Bansal wrote:
> 2.  I would certainly love smaller more regularly updated extracts!  I'm
> not sure how much my team would pay for it though.

The downloads are free of charge. Maybe I should check with the
Interline folks, I don't want to step on their toes with anything.

> 3.  I think the most common analysis patterns rely on regions greater
> than each county, but smaller than just NorCal and SoCal.  The 6
> californias here: https://en.wikipedia.org/wiki/Six_Californias 
> is pretty close to what I would suggest (except i'd have the Bay Area 9
> county region to be one group, perhaps the 7th California?).  I don't
> know of any spatial files with this breakdown.

Creating the split bounds is probably the least difficult part of the
puzzle. Reason I'm asking the locals is that I want to create a split
that is as useful as possible so thank you for the pointer - is the "six
Californias" idea well-known enough that someone in, say, Napa County
would immediately know to look for themselves in "North California" and
not in "Jefferson" or "Central California"?

While I don't *like* overlapping areas, it would be *possible* to have
them if it matches what people expect to find. I could do
SoCal+NorCal+Bay Area, or the 6 Californias plus Bay Area, or whatever.

Bye
Frederik

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

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

Re: [Talk-it] Inserimento dati CAI

[Max]

Grazie per i consigli Alfredo, non avevo mai preso in considerazione il
Protlach, lo proverò e sulla base dei feedback di quest'anno sceglierò
l'editor più adatto per il corso del prossimo anno.

Anche sul Locus si ha la possibilità di importare layer WMS, e quindi di
usare carte tecniche regionali e carta IGM 25000, molto importante per noi
a sud dal momento che qui quasi non esistono carte escursionistiche di
facile reperibilità.

Riguardo la scelta dell'app su cui basare il corso nella mia sezione CAI,
ho preferito il Locus per una feature molto importante per fare rilievi sul
campo ai fini della mappatura su OSM: durante la registrazione della
traccia è possibile aggiungere in modo semplice e rapido waypoint di tipo
vocale, fotografico o video, con possibilità di esportare traccia e
waypoint in un unico package KMZ. Non sono riuscito a trovare una
funzionalità analoga e altrettanto comoda su Oruxmap, Alpine Quest, ecc. ma
magari mi sbaglio...

Altri punti di forza di Locus rispetto ai suoi competitor (tutti ottimi a
dire il vero) sono la possibilità di georeferenziare rapidamente e
utilizzare come layer scansioni o fotografie di mappe (per esempio foto
scattate al volo su pannelli informativi), e una funzione di pianificazione
del percorso molto ben fatta che consente ad esempio di verificare sul
campo i tempi di percorrenza di un percorso alternativo durante
l'escursione.

Max

Il giorno mar 6 nov 2018 alle ore 13:09 Alfredo Gattai <
alfredo.gat...@gmail.com> ha scritto:

> Ce ne sono si e se qualcuno e' abituato con quelle continui pure. Io in
> fase di pianificazione uso molto Orxumap perche' ci carico sotto tutte le
> CTR della mia regione e vedo dove sono vecchi tracciati che ora sono
> invisibile. Georesq pero' ha il vantaggio che per l'attivita'
> escursionistica e per il semplice rilievo di chi fa monitoraggio e' piu'
> semplice ed immediato. Ora poi che sono stati risolti i problemi di consumo
> batteria e ci sono anche le mappe off-line va decisamente bene.
>
> Alfredo
>
> On Tue, Nov 6, 2018 at 11:55 AM Max  wrote:
>
>> Si, ho consigliato di usare sempre il GeoResQ in background e in modalità
>> tracciamento oltre che per le richieste di aiuto, ma per mappe e strumenti
>> GPS disponibili IMHO ci sono app più funzionali e complete come il locus
>> map da usare in foreground rispetto al GeoResQ.
>>
>> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-ca] Stats Canada building outline import plan

[john whelan]

https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan


I've formally submitted it to the imports mailing list for comments and
comments are invited here for the next two weeks.

After that the plan is to start the import process.

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

Re: [Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[santamariense]

Obrigado pessoal pelo feedback. Fiz na calculadora de campo mesmo a
formatação dos nomes e números, quanto a isso tá suave.

Trebien, talvez não tinha explicado direito, mas de qualquer maneira
acho que o Sérgio já deixou claro. O reposicionamento do centroide
para junto dos logradouros será feito antes de se enviar ao OSM.

Paulo, não me parece fácil de implementar. Mas vou tentar. Se não
conseguir vai ser manualmente mesmo.

Uma questão que me foi sugerida fora da discussão aqui da lista é de
não usar source=Prefeitura em todos os pontos gerados, mas sim apenas
nas changesets. Algum forte motivo para manter a source em todos os
pontos?

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

[OSM-talk] Garmin GPS and OSM-based maps (was: Re: How to get an overview of multiple gpx on OSM map?)

[Andy Townsend]

Whilst it's great that Garmin are offering the convenience pre-installed 
OSM-based maps, it's worth bearing in mind that there are lots of free 
download options - see https://wiki.openstreetmap.org/wiki/Mkgmap for 
creating your own and 
https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Download for 
ready-made downloadable options.


http://garmin.openstreetmap.nl/ is a good place to start for "I want 
maps for a certain part of the world".


There are lots of help questions about the mechanics of installing maps 
on Windows, Linux, MacOS etc. at https://help.openstreetmap.org/ , and 
these might be an easier place to start reading than the wiki (which can 
be a bit confused at times).


I do have a GPSMap64s with preinstalled Garmin maps* that aren't 
OSM-based.  One problem with those is that they contain lots of old, 
inaccurate non-OSM POIs that it's impossible to turn off without 
removing the SD card - hopefully your OSM-based maps from Garmin won't 
share this problem.


Re EGNOS on an Etrex 35, assuming it's similar to an Etrex 30x, it's 
noticeably more accurate (within a few meters as opposed to a few tens 
of meters) when you're somewhere with WAAS/EGNOS coverage compared to 
when you're not (in my case it was Europe with and Australia without, 
but that was a while ago - don't know if the Australian situation has 
changed).


Barometric altimeter (on both Etrex30x and GPSMap64s) tend to be 
accurate to within 10m at the top of the hill if you've calibrated them 
at the bottom, but not if you haven't (apologies for being Captain 
Obvious there!).


Battery use on both Etrex30x and GPSMap64s are something like "one pair 
of rechargeable AA batteries every day and a half" (if it's on all day).


Re the new 66s my understanding is that it can use 2 of 
GPS/Glonass/Galileo at the same time.  Personally I'd wait to see a 
"review involving OSM-based map use" before getting one, but I'm sure 
they'll appear fairly soon.


Other non-Garmin options for "something to last all day" might be an old 
phone with GPS in it and user-removable batteries.  An old Blackberry 
might be an option (they still work after you manage to drop them on the 
floor, and you might find the keyboard more usable than a touchscreen 
when it's cold).


Best Regards,

Andy

* at the time this was essentially "free" due to availability and what 
stock the various discounters carried - in theory its about £60 extra, 
and probably isn't worth that.



On 06/11/2018 11:37, Oleksiy Muzalyev wrote:

Thank you, dikkeknodel.

I also received an email message with an advice to acquire Garmin 
eTrex.  I've ordered the Garmin eTrex 35 Touch with the pre-installed 
«TopoActive» Karte Europa, which is based on the OSM data, as I 
understood:

https://www.brack.ch/garmin-hand-gps-etrex-touch-370929

It supports the EGNOS, European Geostationary Navigation Overlay 
Service, which is supposed to correct the GPS signal. I have no idea 
how it works in reality. It also has got the GPS and barometric 
altimeters.


Best regards,
Oleksiy



On 05.11.18 19:59, _ dikkeknodel wrote:


Hi all,

Thanks for all the great advice. I’ve looked into uMap and it does 
the job perfectly. With all the gpx of over a year of hiking imported 
it still runs smoothly.


I would like to prevent running into performance issues later though. 
Does anybody know if it is wise to add ‘simplified’ versions of the 
gpx to uMap instead of the original recordings with 1 s resolution?


Since the published data is public, I just have to take into account 
not to import gpx which start from my home since I value my ‘sort of 
anonymity’.


*@Oleksiy*

To answer Oleksiy’s question, I record with OSMand on a Moto G4 
smartphone, that works like a charm. Off course there is fluctuation 
due to accuracy errors, I guess 10-15 m is achievable most of the 
time, but close to near vertical mountains it becomes much worse.


It however does never happen that I miss long stretches of data 
(except for tunnels ). I did have that problem in the past, when 
<15% battery charge and Android automatically started the battery 
saving mode. That just turned of the gps antenna whenever the screen 
was off. So now I have set battery saving mode to off.


Also OSMand does not drain the battery much. Usually I do take a lot 
of notes which OSMand attaches to the gpx and loads perfectly into 
JOSM. Recently I also used the voice recorder of OSMand, which really 
speeds up the note taking while on the go in comparison to typing. 
These also load into JOSM via the gpx, but some fiddling with the 
location of the audio is required. Taking notes on the phone does 
have an effect on the battery life off course. A 20 km hike in the 
mountains easily takes 6-8h, which my phone reaches most of the time 
on one charge in flight mode. I do have a power-bank as back-up, and 
for multi-day hikes though.


Altitude measurements have always been a bit tricky with OSMand. I 
guess the raw elevation data from 

Re: [Talk-de] POIs - Details - Gerichtsurteil

[sepp1974]

 

Am 06.11.2018 12:43 schrieb Martin Koppenhoefer:
> ...
> 
> wenn Du das so siehst sind wir uns einig, weil in Operator tragen wir die
> Firmennamen ein. Thema erledigt, oder?
> 
> Gruß,
> Martin
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

Nicht ganz, Operator/Betreiber bleibt bei natürlichen Personen unbedingt
leer <= DAS ist das Feld, unter dem der Personenbezug in der Datenbank
hergestellt werden kann und wird.

Eigenname:Fimenname (und zwar vollständig in der korrekten Schreibweise)

Hierzu muss (!!!) u.a. dieser Wiki-Artikel zwingend mit dem Verweis auf
die DS-GVO überarbeitet werden.
=> https://wiki.openstreetmap.org/wiki/DE:Key:operator

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

Re: [OSM-talk-fr] Projet du mois de novembre: gendarmerie/police

[Donat ROBAUX]

Merci Phyks pour le fichier. Je ne l'avais pas vu sur data.gouv. Je ne vois
pas comment l'intégrer dans le Projet du mois vu la gueule du fichier (au
passage, c'est un scandale de proposer ca dans le cadre de l'opendata),
mais je pense qu'on pourra s'en servir a posteriori pour qualifier les
"police", sans attribut particulier sur OSM et qui resteraient après le
projet. Il y aura de fortes chances pour que ce soit des polices
municipales.

Donat


-- Forwarded message --
> From: Phyks 
> To: talk-fr@openstreetmap.org
> Cc:
> Bcc:
> Date: Mon, 5 Nov 2018 23:47:53 +0100
> Subject: Re: [OSM-talk-fr] Projet du mois de novembre: gendarmerie/police
> Salut,
>
> > (je n'ai pas trouvé de source officielle pour un nombre de commissariats
> > de police municipale, n'hésitez pas si vous avez ça sous la main)
>
> Je ne sais pas trop ce que ça vaut, mais je viens de voir passer
>
> https://www.data.gouv.fr/fr/datasets/police-municipale-effectifs-par-commune/
> .
>
> Le fichier est pas forcément de qualité top, et ça concerne les
> effectifs plutôt que les commissariats, mais en comptant les communes
> avec un nombre de policiers municipaux > 0, ça peut peut être déjà
> donner une borne inférieure.
>
> --
> Phyks
>
> >
> > Le 04/11/2018 à 22:26, Vincent de Château-Thierry a écrit :
> >> Bonsoir,
> >>
> >>> De: "Noémie Lehuby" 
> >>>
> >>> Le 04/11/2018 à 11:26, lenny.libre a écrit :
>  +1 avec Vincent, du fait de la présence des polices municipales
>  même s'il n'est pas très utilisé, mais il faudrait définir si on
>  utilise
>  la valeur "police_municipale" ou "police municipale"
> >>> C'est un peu dommage de devoir créer un nouveau tag juste pour
> >>> regrouper les polices municipales (vu qu'operator fait bien l'affaire
> >>> pour les
> >>> deux autres) mais pourquoi pas, ça fait sens.
> >>> Je vais laisse modifier la page FR:amenity=police et on voit comment
> >>> on peut l'inclure dans notre #projetOSMDuMois en cours ?
> >> J'ai modifié la page FR:amenity=police, en optant pour les valeurs
> >> "police", "gendarmerie" et "police_municipale". On pourra changer
> >> cette dernière ensuite s'il y a débat, mais au moins on construit une
> >> typologie des organismes avec un tag ad'hoc.
> >>
> >> vincent
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] [OT] Confini Croazia

[Daniele Forsi]

Il giorno mar 6 nov 2018 alle ore 12:28 Sergio Manzi ha scritto:

>  penso che sarebbe opportuno avere anche un profilo del territorio definito 
> dalla linea di base, cosa che mi sembra capire oggi non ci sia

penso che dovresti fare qualche ricerca nei dati per capire se c'è

io non ne so POCO ma le singole way della linea di base non sono
inserite in una relazione (ne ho controllate un paio manualmente)

Sbaglio qualcosa?

boundary_type=baseline
https://overpass-turbo.eu/s/DqN

boundary=maritime
https://overpass-turbo.eu/s/DqO
-- 
Daniele Forsi

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

Re: [Talk-it] tracciamo il futuro di OpenStreetMap in Italia?

[Matteo Zaffonato]

Il 05/11/2018 21:18, Cascafico Giovanni ha scritto:



Il lun 5 nov 2018, 20:59 Aury88 > ha scritto:



la mia domanda è perchè non proviamo ad aumentare  le voci con
coordinate
geografiche e/o riferimenti, all'interno delle voci, con un qualche
collegamento ad OSM (una sorta quindi di link interno ma che non
punta ad un
articolo ma ad un marker sulla mappa)?


Aggiungerei, voci "mirate". Per esempio, se casca il 100° 
dall'armistizio si completa la voce del sacrario di Redipuglia




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


Qualcosa c'è già, basta guardare il progetto Wikidata.

Ciao
Matteo

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

Re: [Talk-de] POIs - Details - Gerichtsurteil

[Stefan Kaufmann]

Am 06.11.18 um 09:41 schrieb Martin Koppenhoefer:

> Darf man ein Rathaus mappen, wenn man dadurch implizit auch mappt wo der 
> Bürgermeister sein Büro hat, sind das nicht Daten die personenbeziehbar sind? 
> Oder gibt es evtl Grenzen bei der „Personenbeziehbarkeit“? Alle Daten die 
> sich nicht auf natürliche Dinge und Tote beziehen sind irgendwie 
> personenbeziehbar, es kommt darauf an, welche Bezüge der Auswerter herstellt.

_Wo_ das Buergermeisterbuero ist, ist kein personenbezogenes Datum,
sondern eine Funktionsbezeichnung eines Raums. Wenn dort „Buero
Buergermeister Koppenhoefer“ stehen wuerde, ist das etwas anderes. In
ersterem Fall wuerde der Personenbezug erst durch die Zuordnung
„Buergermeiser == Koppenhoefer“ hergestellt werden. Das ist in der OSM
nicht der Fall.


> es geht nicht um alles was irgendwie erkennbar ist, sondern um Firmennamen. 
> Niemand will hier Klingelschilder von Privatleuten mappen oder ähnliches.

Das ist hier aber ein Spezialfall. Die Rede war in der Diskussion auch
davon, den Inhabernamen mit zu mappen. Das ist eine andere Liga als der
Name der juristischen Person (Firma).


>> 2. den bestehenden Datensatz zu sichten und automatisiert und/oder händisch 
>> auszusortieren und
>> 3. (falls das zuviel oder nicht umsetzbar ist) die Erfassungsmöglichkeit 
>> generell zu deaktivieren und damit auf derartige Daten generell zu 
>> verzichten.
> 
> mal sehen, 2 halte ich für theoretisch denkbar, 3 ist technisch unmöglich, 
> zumindest solange man beliebige tags nutzen kann.

Naja, sollten Personen tatsaechlich ihre Rechte nach DSGVO gegenueber
der OSM geltend machen wollen, ist die angenommene Denk- oder
Machbarkeit eigentlich zweitrangig. Was getan werden muss, bestimmt das
Gesetz.

regards,
-stk

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

Re: [Talk-it] [OT] Confini Croazia

[Martin Koppenhoefer]

Am Di., 6. Nov. 2018 um 12:56 Uhr schrieb Martin Koppenhoefer <
dieterdre...@gmail.com>:

> http://www.edizionieuropee.it/LAW/HTML/37/zn67_04_148.html
>


direi che dovrebbero prevalere le descrizioni, per esempio quando c'è
scritto: "Da punto più orientale Isola Caprara (42° 08', 25 - 15° 31', 40)
a punto più orientale isola S. Nicola..." si dovrebbe prendere il punto più
orientale _in OSM_ di quell'isola.

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

Re: [Talk-it] Inserimento dati CAI

[Alfredo Gattai]

Ce ne sono si e se qualcuno e' abituato con quelle continui pure. Io in
fase di pianificazione uso molto Orxumap perche' ci carico sotto tutte le
CTR della mia regione e vedo dove sono vecchi tracciati che ora sono
invisibile. Georesq pero' ha il vantaggio che per l'attivita'
escursionistica e per il semplice rilievo di chi fa monitoraggio e' piu'
semplice ed immediato. Ora poi che sono stati risolti i problemi di consumo
batteria e ci sono anche le mappe off-line va decisamente bene.

Alfredo

On Tue, Nov 6, 2018 at 11:55 AM Max  wrote:

> Si, ho consigliato di usare sempre il GeoResQ in background e in modalità
> tracciamento oltre che per le richieste di aiuto, ma per mappe e strumenti
> GPS disponibili IMHO ci sono app più funzionali e complete come il locus
> map da usare in foreground rispetto al GeoResQ.
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Inserimento dati CAI

[Alfredo Gattai]

Non e' che non sono daccordo, ci mancherebbe, ma il problema e' sempre il
solito, cercare di avvicinare persone che potrebbero non essere
"smanettoni" ad OSM.
Se presentiamo JOSM ad un utilizzatore medio lo facciamo scappare ed invece
vogliamo esattamente il contrario. I corsi vanno un po' fatti a misura
dell'audience
Io di mestiere faccio cartografia elettronica e negli anni ho usato vari
COTS e vari editor proprietari, per alcuni ho contribuito a migliorarne le
funzionalita' e tutt'ora dirigo un reparto di produzione.
Se hai a disposizione un gruppo di persone preparate alle quale puoi fare
un training intensivo ovviamente scegli un'editor potente, rapido e con
pochi controlli automatici che ovviamente non sara' particolarmente user
friendly
Se al contrario hai a disposizione un gruppo di volontari con preparazioni
eterogenee e dai quali non puoi certo pretendere "ritmo di produzione" devi
rendergli la cosa se non piacevole quanto meno poco stressante.

Per i soli scopi dei soci CAI, l'editor che piu' si avvicina a quel che
serve e' Potlach. Che piaccia o no, e' il piu' intuitivo di tutti, ti
permette di fare pochi casini e la presentazione mette in risalto piu'
facilmente anomalie sulle relazioni. Ovviamente e' lento e poco potente ma
ad esempio rispetto a JOSM ti permette di spostarti con calma da una
finestra all'altra scaricando i dati in tempo reale e seguendo la tua
traccia GPX per intero senza dover riscaricare altre zone. Non bisogna
certo avere furia ma e' di tutto relax

Il secondo in ordine di semplicita' e' ID ed ovviamente siccome e' piu'
supportato ci si possono aspettare migliorie in futuro.

Josm non ha bisogno di presentazioni, e' fenomenale, ma la facilita' d'uso
e' tutta un'altra cosa.

Io stesso sono partito da Potlach, poi ho provato ID ed ora uso quasi
esclusivamente Josm.

La mia raccomandazione rimane la stessa, regolate i corsi in base a chi
arriva, Potlach lo posso insegnare anche a mia madre, Josm no.

Alfredo


>
> forse Alfredo non sarà completamente d'accordo, ma per un corso
> consiglierei di partire subito da JOSM: ha più strumenti disponibili e
> può utilizzare il preset CAI che mostra maschere di inserimento dati
> molto intuitive.
> Partendo da https://learnosm.org/it/josm/start-josm/ trovate una guida
> passo passo scaricabile anche in formato pdf.
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Národní archiv leteckých snímků

[Jan Macura]

On Tuesday, 6 November 2018, Marián Kyral  wrote:
>> b) protože "© ČÚZK"
> Kolik že to je? 80 let po smrti autora? A kdo je vlastně autor? :-D

Autorské právo platí 70 let od smrti autora. Nevsadil bych ale na to, že
stejná doba se aplikuje i na "zvláštní právo pořizovatele databáze",
nehledě na to, kdy toto právo nabývá účinnosti...
(Aneb ČÚZK si vždycky výmluvu najde).

H.

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

Re: [Talk-cz] Národní archiv leteckých snímků

[jozka]

citace:

Snímky z let 1936 až 2002 byly pořízeny Ministerstvem obrany České republiky, 
respektive jeho předchůdci. Od roku 2003 jsou snímky pořizovány ve spolupráci 
Českého úřadu zeměměřického a katastrálního a Ministerstva obrany České 
republiky.

konec citace.

Muzeme zacit flejm kdy ze to vlastne MNO/MO umrelo...

J.

__
> Od: "Marián Kyral" 
> Komu: "OpenStreetMap Czech Republic" 
> Datum: 06.11.2018 09:40
> Předmět: Re: [Talk-cz]Národní archiv leteckých snímků
>
>
>> b) protože "© ČÚZK"
>
>
>
>
>Kolik že to je? 80 let po smrti autora? A kdo je vlastně autor? :-D
>
>
>
>
>Marián
>
>
>
>
>
>
>
>-- Původní e-mail --
>Od: Michal Pustějovský 
>Komu: OpenStreetMap Czech Republic 
>Datum: 6. 11. 2018 9:25:36
>Předmět: Re: [Talk-cz] Národní archiv leteckých snímků
>"
>Ahoj,
>
>
>
>
>
>Pavel to popsal přesně.
>
>
>
>
>
>Díky,
>
>
>Michal
>
>
>
>-- Původní e-mail --
>Od: Jan Macura 
>Komu: OpenStreetMap Czech Republic 
>Datum: 5. 11. 2018 23:18:34
>Předmět: Re: [Talk-cz] Národní archiv leteckých snímků
>"
>Ahoj,
>
>
>
>
>On Mon, 5 Nov 2018 at 21:13, Pavel Machek mailto:pa...@ucw.cz)
>> wrote:
>
>" Kouknu az budu u pocitace, ale... proc se nehodi pro mapovani?"
> 
>
>a) protože "Aplikace prezentuje prosté letecké měřické snímky pořízené
>centrální projekcí, nejedná se o ortofotosnímky. Tyto snímky nelze tedy
>použít k přímému měření polohových vztahů mezi zobrazenými geografickými
>objekty."
>
>b) protože "© ČÚZK"
>
>
>
>
>H.
>
>
>
>
>""
>
>
>
>
>
>
>
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>https://openstreetmap.cz/talkcz
>"___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>https://openstreetmap.cz/talkcz
>"
>
>--
>
>___
>Talk-cz mailing list
>Talk-cz@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-cz
>https://openstreetmap.cz/talkcz
>
>

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

Re: [Talk-it] [OT] Confini Croazia

[Martin Koppenhoefer]

Am Di., 6. Nov. 2018 um 12:04 Uhr schrieb Sergio Manzi :

> In realtà esistono delle differenze: un esempio (*ma ce ne sono altri*) è
> che la legge penale di uno stato non si estende alle sue acque territoriali
> quando il fatto avvenga/sia avvenuto su una nave battente bandiera
> differente da quella dello stato stesso, a meno di alcuni specifici casi
> previsti dalla "*Convenzione delle Nazioni Unite sul diritto del mare*"
> [1].
> Sul fatto se, in OSM, sia opportuno o meno includere le acque territoriali
> nei confini amministrativi degli stati, sinceramente ho dei dubbi, anche
> perché penso che la cosa potrebbe essere facile causa di vari "*incidenti
> diplomatici*".
>



se ricordo bene, i confini Italiani attuali derivano sopratutto da un
dataset europeo.



>
> Sicuramente penso che sarebbe opportuno avere* anche* indicazioni su
> quale sia la "linea di base", cioè la linea (legale) di costa dalla quale
> poi derivano i diritti sulla fascia di mare antistante.
>


concordo. C'è una legge che contiene le coordinate e anche descrizioni come
nomi di fari ecc.. Si potrebbe utilizzare come una delle fonti originali.
non sò se questa è una fonte ufficiale:
http://www.edizionieuropee.it/LAW/HTML/37/zn67_04_148.html

Ho trovato qui anche indicazioni dove si potrebbe indagare:
http://www.nonnodondolo.it/content/linee-base-e-limiti-delle-acque-territoriali-italiane

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

Re: [Talk-de] POIs - Details - Gerichtsurteil

[Martin Koppenhoefer]

Am Di., 6. Nov. 2018 um 12:03 Uhr schrieb :

> es war Dein Beispiel, über den Betreibernamen einer Kneipe dessen
> frühere Aktivitäten recherchieren zu können, um daraus Rückschlüsse über
> die Qualität der angebotenen Dienstleistung zu konstruieren. Ich habe
> das lediglich ins positive durch Doppel-D und bauchfrei überspitzt -
> nichts weiter. Nebelkerze???
>


das konkrete Beispiel an das ich dachte war ein Alimentari (Laden mit
Theke, der Wurstaufschnitt, Käseaufschnitt, eingelegte Sachen und so
verkauft), der früher an "Fertigem" nur belegte Brötchen verkauft hat und
jetzt den Namen geändert hat, Tische und Stühle aufgestellt hat und einen
Mittagstisch anbietet und kaum noch Wurst und Käse anbietet. Anhand von
meinen alten OSM Daten konnte ich sehen, dass es immer noch derselbe
Betreiber ist. Ähnlich auch bei einem Kebab Imbiss.


Ich vertrete die Meinung, dass
> personenbezogene Daten in dieser Datenbank nichts zu suchen haben. Ein
> Firmenname ist kein personenbezogener Datenbestand, selbst wenn die
> Firma nach dem Inhaber namentlich benannt ist - da existiert durchaus
> ein kleiner aber feiner Unterschied. Wenn eine Firma aufgrund geltenden
> Rechtes im Firmennamen mit dem aktuellen Inhaber benannt werden muss,
> sehe ich darin überhaupt kein Problem, diese Firma entsprechend der
> Schreibweise und Inhalt zu mappen.



wenn Du das so siehst sind wir uns einig, weil in Operator tragen wir die
Firmennamen ein. Thema erledigt, oder?

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