date:20181022

Le lun. 22 oct. 2018 à 15:52, Vincent Bergeot  a
écrit :

>
> il me semble surtout que l'on doit arriver à trouver le bon degré de
> discussion car oui OSM fournit une information de qualité mais les
> collectivités possèdent aussi des données de qualité et/ou des bonnes
> volontés pour avancer sur ces sujets. Ces collectivités ont souvent une
> histoire qui rend tout beaucoup plus lent, long c'est sur :)
>
> Je suis cependant d'accord avec toi sur la vigilance à avoir sur leur
> capacité de récupération politique...
>

C'est exactement ça
Merci Vincent d'avoir des mots plus justes

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

Re: [Talk-it-trentino] R: nuovo utente cena quel che l'è...

2018-10-22 Per discussione Francesco Pelullo

Per me Trento ok, mi sposto in macchina ed ho 4 posti, posso prendere gli
osmers di Rovereto, Mori, Ala etc ma anche Riva se serve, oltre a qualcuno
per strada.
Non deve essere per forza Trento, qualunque posto nella valle dell'Adige va
bene.

Ciao
--FP


Il giorno lun 22 ott 2018 alle ore 21:19 Luca Delucchi 
ha scritto:

>
>
> Il lun 22 ott 2018, 20:07 Francesco Pelullo  ha
> scritto:
>
>> quoto!
>>
>
> Tanto sarebbe da capire se Trento o rovereto...
> Se siamo tutti del fondo valle è indifferente, se invece qualcuno arriva
> da distante forse Trento è più centrale /comoda
>
>
>> Ciao
>> --FP
>>
>
> Ciao
> Luca
>
>> ___
> Talk-it-trentino mailing list
> Talk-it-trentino@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it-trentino
>
___
Talk-it-trentino mailing list
Talk-it-trentino@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-trentino

Re: [OSM-talk-fr] Contributeur(e) compulsif(ve) et imprécis, faut faire quoi ?

2018-10-22 Per discussione osm . sanspourriel

> "Corrections" des bâtiment du cadastre (mis à jour à partir du 
fichier etalab de juin 2018) à partir de la BDOrtho, mais là ça frole le 
vendalisme ;-) .

Tu as vérifié l'orthophoto ?
Le cadastre a pour but principal de calculer l'impôt.
J'ai vu des bâtiments tournés à 90° par rapport à la réalité (vérifiable 
par orthophoto).


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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie



sent from a phone

> On 22. Oct 2018, at 21:46, Hubert87  wrote:
> 
> Flächen mit Flächen verbinden -> Ok
> Wege über Flächen legen -> Ok
> Wege mit Flächen verbinden -> (big) NO! 


ausser es sind highway=* und area=yes, oder?


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

Re: [OSM-talk-fr] Re : Re: repère géodésique détruit

2018-10-22 Per discussione osm . sanspourriel


J'ai mis à jour les points et le wiki.

Par contre j'ai laissé la relation à l'identique, celui qui voit les 
fiches mises à jour pourra la mettre à jour (ainsi que les points : pour 
le moment j'ai laissé l'info, ajouté un end_date et ajouté un préfixe.


Jean-Yvon


Le 22/10/2018 à 15:40, Vincent de Château-Thierry - osm.v...@free.fr a 
écrit :

Bonjour,



Voir aussi 
https://wiki.openstreetmap.org/wiki/WikiProject_France/Rep%C3%A8res_G%C3%A9od%C3%A9siques#Supprim%C3%A9s



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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

2018-10-22 Per discussione Hubert87


My two Cents:

Flächen mit Flächen verbinden -> Ok
Wege über Flächen legen -> Ok
Wege mit Flächen verbinden -> (big) NO! Es ist einfach ein heiden 
Aufwand anschließend etwas zu ändern. (Wege trennen, Flächen verfeinern, 
Erweiterung zu area:highway)


VG
Hubert87


Am 19.10.2018 um 15:06 schrieb Frederik Ramm:

Hallo,

leider kommt es immer wieder zu Changeset-Diskussionen wie hier:

https://www.openstreetmap.org/changeset/63602349

Irgendein Neuling mappt irgendwas mit "zusammengeklebten" Flächen,
irgendeiner meckert dran rum, dann kommen flohoff und OF0 und hauen noch
obendrauf, weil sie ihren privaten Kreuzzug führen, und zurück bleibt
ein Neuling mit einem Riesen-Fragezeichen im Gesicht, der gar nicht
versteht, was er da ausgelöst hat.

Das ist nicht gut. Wenn diese Debatte nicht projektweit oder wenigstens
deutschlandweit vernünftig geführt und das Problem nicht gelöst werden
kann, dann sollte man auch nicht versuchen, "seine" Ansicht ungefragt
armen Newbies aufs Auge zu drücken, nach dem Motto, die können sich ja
nicht wehren.

Ich werde Benutzer, die sich in solche Changeset-Diskussionen
verzetteln, künftig deswegen sperren.

Bye
Frederik




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

Re: [Talk-it] quartiere

2018-10-22 Per discussione Alecs

Concordo sulla prima parte, ma per la relazione userei type=multipolygon e
place=neighborhood
boundary=administrative presuppone che si tratti di una suddivisione
amministrativa non solo di un semplice quartiere, e in Italia le
circoscrizioni interne ai comuni esistono solo per i comuni maggiori (sopra
i 250 mila abitanti) e non è il caso di Faenza che io sappia:
https://www.openstreetmap.org/relation/8839603/history

Ciao
Alecs


danysan95 wrote
> Cosa intendi con "aveva inglobato la città intera"?
> Se intendi che in tutta la città i risultati delle ricerche dicevano che
> il
> posto fosse in quel neighborhood, il problema non era il nodo in se ma il
> fatto che non avesse confini.
> Anche la pagina wiki di place=neighborhood [1] avverte del problema: "When
> tagged as node, all the sorrounding addresses refer to this node and the
> corresponding address is often wrong, expecially near borders. *Fix*:
> using
> area/relation to define the boundary".
> In questo caso la soluzione NON è eliminare il nodo ma è mappare i confini
> del neighborhood.
> 
> Per mappare i confini prima di tutto devi creare i singoli segmenti di
> confine come way e taggarli con boundary=administrative+admin_level=10
> .[2]
> Quindi devi creare una relazione  taggata
> type=boundary+boundary=administrative+admin_level=10 .[3]
> Infine devi aggiungere come membri della relazione tutti i segmenti con
> ruolo "outer" e il place=neighborhood con ruolo "admin_centre".
> Lo stesso discorso vale se invece di un place=neighborhood hai un
> place=suburb/quarter/...
> 
> Se non conosci i confini esatti invece sei "in braghe di tela" perchè non
> c'è una soluzione (che io sappia).
> 
> [1] https://wiki.openstreetmap.org/wiki/Tag:place%3Dneighbourhood#Issues
> [2]
> https://wiki.openstreetmap.org/wiki/Tag:boundary=administrative#10_admin_level_values_for_specific_countries
> https://wiki.openstreetmap.org/wiki/Tag:boundary=administrative?uselang=it#10_admin_level_values_for_specific_countries;
> [3] https://wiki.openstreetmap.org/wiki/Relation:boundary
> https://wiki.openstreetmap.org/wiki/Relation:boundary?uselang=it;
> 
>>
> 
> ___
> Talk-it mailing list

> Talk-it@

> https://lists.openstreetmap.org/listinfo/talk-it





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

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

Re: [Talk-it-trentino] R: nuovo utente cena quel che l'è...

2018-10-22 Per discussione Luca Delucchi

Il lun 22 ott 2018, 20:07 Francesco Pelullo  ha
scritto:

> quoto!
>

Tanto sarebbe da capire se Trento o rovereto...
Se siamo tutti del fondo valle è indifferente, se invece qualcuno arriva da
distante forse Trento è più centrale /comoda


> Ciao
> --FP
>

Ciao
Luca

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

Martin, genau das steht dort nicht. Way ist keine Fläche.

Es steht dort, dass das Nutzen von gemeinsamen Notes einer Fläche und 
einer Linie nicht erwünscht sind und genau das muss man dem Neuuser auch 
bildlich darstellen, denn der mappt nach Karte und dort werden way's 
anhand ihrer Attribute als "Fläche" optisch dargestellt.

Wie schauts aus mit meinem Vorschlag, die Verkehrsfläche als solches zu 
mappen und zu verkleben?

Ich stelle mir das mit den unverklebten Flächen immer so vor, dass der 
Luftballon OSM gar nicht aufzublasen geht mit den vielen Löchern und 
Zwischenräumen, die da durch's Trennen der Flächen wo keine Trennung 
ist, praktiziert wird. Es wird immer der schlaffe, luftleere, kaputte 
Ballon bleiben ;-)

Gruß Sepp

Am 22.10.2018 19:28 schrieb Martin Koppenhoefer:
Am Mo., 22. Okt. 2018 um 18:23 Uhr schrieb Christoph Hormann 

:

On Monday 22 October 2018, Frederik Ramm wrote:
> Man könnte das ja auch als oneway-Regel ähnlich wie das mit der
> groben Ersterfassung formulieren:
>
> 1. Du kannst eine Straße quer durch einen Wald malen.
>
> 2. Du kannst den Wald auch entlang der Straße - mit Verkleben - in
> zwei Teile teilen.
>
> 3. Wenn dann jemand kommt und das schön entklebt, ist das ok.
>
> 4. Du kannst niemals einen entklebten Wald entlang einer Straße
> wieder verkleben.

Klingt gut - und das ist denke ich auch weit verbreitet die gelebte
Praxis.

+1. Im Prinzip genau wie bei anderen Flächen die an Straßen geklebt 
werden.
Es wird dahingehend präzisiert, dass zwar beide Methoden in Verwendung 
sind
und ihre Berechtigung haben, dass sie aber keinesfalls gleichwertig 
sind,

und das Verkleben von bereits "entklebten" Flächen nicht gewünscht ist.

Gruß,
Martin
___
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

Wochennotiz Nr. 430 09.10.2018–15.10.2018

2018-10-22 Per discussione Wochennotizteam

Hallo,

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

http://blog.openstreetmap.de/blog/2018/10/wochennotiz-nr-430/

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

Wochennotiz Nr. 430 09.10.2018–15.10.2018

2018-10-22 Per discussione Wochennotizteam

Hallo,

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

http://blog.openstreetmap.de/blog/2018/10/wochennotiz-nr-430/

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

[Talk-it-trentino] R: nuovo utente cena quel che l'è...

2018-10-22 Per discussione paolo ....

In attesa di location

Fam. Pizzini
Via Maffei 2 
38068 Rovereto TN
piz...@hotmail.it

-Messaggio originale-
Da: Luca Delucchi [mailto:lucadel...@gmail.com] 
Inviato: giovedì 18 ottobre 2018 02:11
A: OpenStreetMap Mailing List Trentino
Oggetto: Re: [Talk-it-trentino] nuovo utente cena quel che l'è...

On Tue, 16 Oct 2018 at 19:50, Francesco Pelullo  wrote:
>
>
> Lascio a voi la scelta, per me va bene sempre ed ovunque tranne qualche 
> week-end in cui non ci sono.
> Magari se la cena è impegnativa, potremmo considerare anche una cosa piu' 
> soft.
>

come si vuole, anche un paio di birre al pub vanno bene :-)

> Mi sembra che martedi' prossimo ci siano parecchie disponibilità, magari si 
> potrebbe fare martedi' 23.
> Invito quelli che hanno messo "no" a riesaminare la cosa (non soltanto il 23, 
> anche negli altri giorni).
>

direi che dovrei riuscire a liberarmi il 23, la confermiamo?

Ora dobbiamo decidere dove...

> Oppure vi invito a cena a casa mia, non sono un granche' come cuoco ma una 
> bottiglia di vino la tengo sempre pronta.
>
> Ciao
> Francesco
>


-- 
ciao
Luca

www.lucadelu.org

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

Re: [OSM-talk-ie] Collinstown Townland has been re mapped as Dublin Airport!

2018-10-22 Per discussione Patrick Matthews

I'm not sure if anyone would be able to identify changesets and whether
they could be rolled back to their pre-"redrawing" stage.

On Mon, Oct 22, 2018 at 5:50 PM Brian Hollinshead 
wrote:

> Thanks Paddy,
> I found Belgard Quarry this morning. At least in that case they left the
> townland boundaries intact so it could be easier to fix, Is that in your
> field of expertise or I am hoping for someone else to kindly offer?
>
> On Mon, 22 Oct 2018 at 15:19, Patrick Matthews 
> wrote:
>
> > Looking around last night, something similar seems to have been done at
> the
> > Belgard quarry on the south side of Dublin and looking at the relevant
> > relation history it seems to be the same few names who are involved in
> > freelance boundary redrawing in both locations. I'm sure there may be
> other
> > places where this has gone on but that was the one that I noticed.
> >
> > Paddy Matthews.
> >
> > On Sun, Oct 21, 2018 at 12:29 PM Brian Hollinshead <
> br...@hollinshead.net>
> > wrote:
> >
> > > While adding the Malahide Union of parishes to the map which uses a
> > > combination of the old civil parish boundaries I find that Collinstown
> > > townland (relation/5436241) has been seriously redrawn if compared to
> the
> > > GSGS 3906 map and maps.openstreetmap.ie. Rorys townlands.ie shows the
> > post
> > > changes state.
> > > It looks as thought someone thought Collinstown Airport was the new
> > > townland.
> > >
> > > The border between townland of Forrest Little(relation 5440762) and
> > > Clonshaugh, Corballis and Huntstown has been quite altered between
> > > 53.435847/-6.236136 and 53.4316541/-6.2644.
> > >
> > > I believe this also alters some Barony and Superintendent Registrars
> > > District boundaries so feel it is highly preferable that these changes
> be
> > > reversed intact.
> > >
> > > I regret this is way above my capability so I ask for someone reading
> > this
> > > to please address this issue.
> > >
> > > Thank you for your kindness.
> > >
> > > By the way, Many thanks to those organised such an enthusiastic meeting
> > in
> > > Maynooth yesterday, the future looks good.
> > > ___
> > > Talk-ie mailing list
> > > Talk-ie@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-ie
> > >
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

Am Mo., 22. Okt. 2018 um 18:23 Uhr schrieb Christoph Hormann :

> On Monday 22 October 2018, Frederik Ramm wrote:
> > Man könnte das ja auch als oneway-Regel ähnlich wie das mit der
> > groben Ersterfassung formulieren:
> >
> > 1. Du kannst eine Straße quer durch einen Wald malen.
> >
> > 2. Du kannst den Wald auch entlang der Straße - mit Verkleben - in
> > zwei Teile teilen.
> >
> > 3. Wenn dann jemand kommt und das schön entklebt, ist das ok.
> >
> > 4. Du kannst niemals einen entklebten Wald entlang einer Straße
> > wieder verkleben.
>
> Klingt gut - und das ist denke ich auch weit verbreitet die gelebte
> Praxis.



+1. Im Prinzip genau wie bei anderen Flächen die an Straßen geklebt werden.
Es wird dahingehend präzisiert, dass zwar beide Methoden in Verwendung sind
und ihre Berechtigung haben, dass sie aber keinesfalls gleichwertig sind,
und das Verkleben von bereits "entklebten" Flächen nicht gewünscht ist.

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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

2018-10-22 Per discussione Any File

On Mon, Oct 22, 2018 at 10:37 AM Cascafico Giovanni  wrote:

> Ma il nome volgare "Farnia" dove lo metto?

In species:it

come indicato negli esempi che ci sono nella pagina de te indicata,
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree

oppure come spiegato in https://wiki.openstreetmap.org/wiki/Key:species


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

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

Re: [OSM-talk] Fwd: DWG policy on Crimea

2018-10-22 Per discussione Oleksiy Muzalyev

The situation with Crimea is not clear-cut. It is kind of complicated.
For instance, the climate in Crimea is very dry, that is why the water
from the river Dnieper had been transferred to Crimea by an immense
artificial North Crimean Canal [1]. Now the Dnieper water is not sold to
Crimea any more.

The newspaper Le Monde named Rana Dasgupta one of 70 people who are
making the world of tomorrow [2]. Speaking figuratively, an electrician
may work with wires without knowing Maxwell's equations or Ohm's law
formulas. Still, it is better that he has some notion of the theory of
electromagnetism.

The same is here. We try to discuss border dispute between the nation
states. I just recommended to read an article [3] of the well known
essayist and thinker about the nation state evolution as a political,
economical, and philosophical concept. It will not solve this dispute,
but at least, its nature could be better understood.

[1] https://en.wikipedia.org/wiki/North_Crimean_Canal
[2] https://en.wikipedia.org/wiki/Rana_Dasgupta
[3]
https://www.theguardian.com/news/2018/apr/05/demise-of-the-nation-state-rana-dasgupta

Best regards,
Oleksiy

On 22.10.18 15:25, Mateusz Konieczny wrote:
Can you summarize parts of this article (5k+ words, in "long read"
section) that are relevant to

tagging of Russian and Ukrainian border in the Crimea?

22. Oct 2018 00:44 by oleksiy.muzal...@bluewin.ch
:

Hi Martin,

Before continuing this discussion further, I would advise to read
the amazing article "The demise of the nation state" by Rana
Dasgupta available via this link:

https://www.theguardian.com/news/2018/apr/05/demise-of-the-nation-state-rana-dasgupta

The issue of national state boundaries is more profound and
ubiquitous than it may seem at first sight. This topic is
controversial and complicated, and Rana Dasgupta's analyses
provides some good starting-point insights.

Best regards,
Oleksiy

On 21.10.18 16:12, Martin Koppenhoefer wrote:

Dear all,

we all know how sensible the topic of disputed boundaries can
be (they are not necessarily a big problem, many boundary
disputes like between Italy and France about the summit of
Mont Blanc / Monte Bianco, have little bearing on the actual
life of people).

Therefore we can all be satisfied there is clear guidance from
the board how to deal with this: the local situation
determines how we map, and the OSMF is explicit here:
“National borders are particularly sensitive. Currently, we
record one set that, in OpenStreetMap contributor opinion, is
most widely internationally recognised and best meets
realities on the ground, generally meaning physical control.”

https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.

pdf

When I recently looked at Crimea I noticed it is still part of
the Ucraine in OSM: https://www.openstreetmap.org/relation/60199

As many might know, the current boundary situation for Crimea
was frozen 4 years ago “for a short time” by the DWG and so I
asked them about their current position 2 months ago, and
after I got no reply, tried to remind them 5 weeks ago, but
have not yet gotten any reply, so I am now opening this thread
here.

IMHO, for consistency and credibility, we should either
recognize that Russia is actually controlling Crimea, or we
should update the disputed borders information. As I believe
the general concept of ground truth for admin boundaries was a
good idea, I would tend to the former.

I also believe the actual situation has already been ignored
for too long. When the thing is still dynamic or/and we’re in
the middle of a conflict it can be wise to step back and see
for some time how things are evolving, but 4 years are a lot
of time, something like one year would seem more reasonable.

What do you think?

Cheers, Martin

sent from a phone

Begin forwarded message:

*From:* Martin Koppenhoefer mailto:dieterdre...@gmail.com>>
*Date:* 20. August 2018 at 10:42:33 CEST
*To:* d...@osmfoundation.org
*Subject:* *DWG policy on Crimea*

Dear members of the DWG,

as of this question in the help forum:

https://help.openstreetmap.org/questions/65436/what-is-the-current-position-of-the-dataworkinggroup-on-crimea

I kindly invite you to reconsider and eventually update
your position on the situation in Crimea.

As you have stated in 2014, this should not be the long
term way to deal with the

Re: [OSM-talk-fr] Osmose - Délai

2018-10-22 Per discussione Jean-Marc Liotier

On Mon, October 22, 2018 6:46 pm, Adrien André wrote:
>
> à quoi correspond la valeur "Délai" affichée sur l'interface web
> d'Osmose ?

Délai entre le dernier changeset analysé par Osmose et le dernier
changeset de la base de données Openstreetmap.

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

Re: [OSM-talk-ie] OpenStreetMap Ireland CLG launch yesterday

2018-10-22 Per discussione Brian Hollinshead

We can also add Carlow and Galway County Councils, Geological Survey
Ireland. Bus Eireann,

Please what is the correct format of the Company name and does it have a
number yet?

On Mon, 22 Oct 2018 at 13:31, Colm Moore  wrote:

> Ciarán & board,
>
> Well done on setting things up!
>
> One thing we might do is to promote OSM, based on those that are using the
> data already:
>
> * NTA: www.rtpi.ie
> * Dublin Fire Bridge - maps on Twitter.
> * Dublin City Council self service portal -
> http://www.dublincity.ie/main-menu-your-council/isupport
> * Met Éireann - https://www.met.ie/
>
> I'm sure there are more.
>
> Colm
>
>
>
> ---
> Never doubt that a small group of thoughtful, committed citizens can
> change the world. Indeed, it is the only thing that ever has. Margaret Mead
>
>
>
> From: talk-ie-requ...@openstreetmap.org  >
> Sent: 22 October 2018 13:01
> To: talk-ie@openstreetmap.org
> Subject: Talk-ie Digest, Vol 113, Issue 10
>
>
> Send Talk-ie mailing list submissions to
> talk-ie@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openstreetmap.org%2Flistinfo%2Ftalk-iedata=02%7C01%7C%7C30ba719ee5de45c1532608d63817087f%7C84df9e7fe9f640afb435%7C1%7C0%7C636758068903216965sdata=aYM1N3lSYoxr4dDzI38BjfnOQVDuIX3JjqjP2EW7tEo%3Dreserved=0
> or, via email, send a message with subject or body 'help' to
> talk-ie-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> talk-ie-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Talk-ie digest..."
>
>
> Today's Topics:
>
>1. Re: OpenStreetMap Ireland CLG launch yesterday (Ciarán Staunton)
>
>
> --
>
> Message: 1
> Date: Sun, 21 Oct 2018 13:08:58 +0100
> From: Ciarán Staunton 
> To: Discussion of OpenStreetMap in Ireland 
> Subject: Re: [OSM-talk-ie] OpenStreetMap Ireland CLG launch yesterday
> Message-ID:
> <
> caa66pxlwcyerymwsbb5axrqpgoaggnygxmdqdwkg_uyuwss...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Greetings All
> On behalf of the board I want to thank you for attending the launch and the
> open mic event yesterday.
>
> For the benefit of those that missed it we saw a fantastic look back at the
> history of the community from mackerski. dónál went through the legalities
> of the company set up, how we got to where we are now and that we will be
> formally applying for chapter status with osmf. I myself (debigc) let
> everyone know what to expect in term of activity for the next year, as we
> bring the participation, connection, visibility and exchange to the next
> level.
>
> The open mics were all really interesting too, to summarise them we would
> have to point to the diversity of platforms, motivations, focus, interest
> that is out there in the broader community. The wealth of the asset that is
> openstreetmap is the wealth of the knowledge you are all putting into it.
> As all the speakers at the start said in one way or another pulling
> together and being more coherent as a community is where we are navigating
> to right now.
>
> Keep up the great work everyone!
>
>
> --
>
> Subject: Digest Footer
>
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
>
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openstreetmap.org%2Flistinfo%2Ftalk-iedata=02%7C01%7C%7C30ba719ee5de45c1532608d63817087f%7C84df9e7fe9f640afb435%7C1%7C0%7C636758068903216965sdata=aYM1N3lSYoxr4dDzI38BjfnOQVDuIX3JjqjP2EW7tEo%3Dreserved=0
>
>
> --
>
> End of Talk-ie Digest, Vol 113, Issue 10
> 
>
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [OSM-talk-ie] Collinstown Townland has been re mapped as Dublin Airport!

2018-10-22 Per discussione Brian Hollinshead

Thanks Paddy,
I found Belgard Quarry this morning. At least in that case they left the
townland boundaries intact so it could be easier to fix, Is that in your
field of expertise or I am hoping for someone else to kindly offer?

On Mon, 22 Oct 2018 at 15:19, Patrick Matthews 
wrote:

> Looking around last night, something similar seems to have been done at the
> Belgard quarry on the south side of Dublin and looking at the relevant
> relation history it seems to be the same few names who are involved in
> freelance boundary redrawing in both locations. I'm sure there may be other
> places where this has gone on but that was the one that I noticed.
>
> Paddy Matthews.
>
> On Sun, Oct 21, 2018 at 12:29 PM Brian Hollinshead 
> wrote:
>
> > While adding the Malahide Union of parishes to the map which uses a
> > combination of the old civil parish boundaries I find that Collinstown
> > townland (relation/5436241) has been seriously redrawn if compared to the
> > GSGS 3906 map and maps.openstreetmap.ie. Rorys townlands.ie shows the
> post
> > changes state.
> > It looks as thought someone thought Collinstown Airport was the new
> > townland.
> >
> > The border between townland of Forrest Little(relation 5440762) and
> > Clonshaugh, Corballis and Huntstown has been quite altered between
> > 53.435847/-6.236136 and 53.4316541/-6.2644.
> >
> > I believe this also alters some Barony and Superintendent Registrars
> > District boundaries so feel it is highly preferable that these changes be
> > reversed intact.
> >
> > I regret this is way above my capability so I ask for someone reading
> this
> > to please address this issue.
> >
> > Thank you for your kindness.
> >
> > By the way, Many thanks to those organised such an enthusiastic meeting
> in
> > Maynooth yesterday, the future looks good.
> > ___
> > Talk-ie mailing list
> > Talk-ie@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ie
> >
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[OSM-talk-fr] Osmose - Délai

2018-10-22 Per discussione Adrien André

Bonjour,

à quoi correspond la valeur "Délai" affichée sur l'interface web d'Osmose ?

Je ne trouve pas de description sur le wiki.

D'avance merci !

Adrien


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

Re: [OSM-talk] Fwd: DWG policy on Crimea

22. Oct 2018 16:59 by colin.sm...@xs4all.nl :


>
> On 2018-10-22 16:34, Mateusz Konieczny wrote:
>
>>
>> I strongly disagree, we map reality.
>>
>
> There is no one true reality, only perceptions. 
>




There is both a true reality and our biased interpretation of it. But it many

cases it is possible to select criteria, rules, categorizations where bias is 
small and

our interpretation align.




But anyway that is a philosophical claim and that discussion is unlikely to 
lead anything useful.

  


>
> Which reality takes precedence in your mind, may not be the same for 
> everyone. Reality is subjective.
>
> What is the test to apply to decide whether a point is included in country A 
> or country B?
>




In case of Russian/Ukrainian border, as defined by on the ground line of 
control 


"is area controlled by Russian army or Ukrainian army" works quite well, better 
than 


"is this area claimed by Russia" or "is this area claimed by Ukraine"



>
> In the case of disputed borders, there are at least two realities (as 
> perceived by the parties to the dispute) and possibly a third reality as 
> perceived by a number of locals
>




There is one reality and multiple interpretations of it. It is preferable to 
map things so that

interpretations are not different between mappers.

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

2018-10-22 Per discussione Christoph Hormann

On Monday 22 October 2018, Frederik Ramm wrote:
>
> Man könnte das ja auch als oneway-Regel ähnlich wie das mit der
> groben Ersterfassung formulieren:
>
> 1. Du kannst eine Straße quer durch einen Wald malen.
>
> 2. Du kannst den Wald auch entlang der Straße - mit Verkleben - in
> zwei Teile teilen.
>
> 3. Wenn dann jemand kommt und das schön entklebt, ist das ok.
>
> 4. Du kannst niemals einen entklebten Wald entlang einer Straße
> wieder verkleben.

Klingt gut - und das ist denke ich auch weit verbreitet die gelebte 
Praxis.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk-fr] repère géodésique détruit

2018-10-22 Per discussione David Crochet


Bonjour

Voila la réponse reçu :

=

Bonjour,


Suite à votre courrier électronique du17/10/2018, j’ai actualisé notre base de 
données en tenant compte de vos informations.
La modification sera visible prochainement sur notre serveur de fiches 
signalétiques.
Merci.

Cordialement


Christina GARREAU
___
Unité de Mise à Jour de la Base de Données Géodésique (BDG)
Service de Géodésie et de Nivellement (SGN)
Direction de la Production
T + 33(0) 1 43 98 83 35 ● F +33(0) 1 43 98 84 50
73, AVENUE DE PARIS, 94165 SAINT-MANDE CEDEX

christina.garr...@ign.fr
ign.fr - geoportail.fr

===

Cordialement

--
David Crochet

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

Re: [OSM-talk-fr] migrer les amenity=swimming_pool (déprécié)

2018-10-22 Per discussione Paul Desgranges

Pas de problème ça me convient très bien, c'est ce que je souhaitais
proposer justement,

je regarde de mon coté tous les cas qui sont exclus de l'édition de masse

/Si je devais le faire />/1- Je corrigerais d'abord les piscines avec un champ nom 'Piscine' />/'Piscine privée' pour mettre ça dans
la "description" />/2- J'enlèverais du traitement massif tout ce qui peut l'être (comme />/mentionné) : />/ les
amenity=swimming_pool nommés (sauf les noms m. ci-dessus à />/traiter individuellement) />/ les amenity=swimming_pool qui sont
aussi building />/ les amenity=swimming_pool qui sont aussi leisure=sports_centre />/ Car tous ceux là ont vocation à devenir des
"leisure=sports_centre />/sports=swimming name=... building=...", (sauf exception donc avec une />/vérification visuelle)
/>/3- Je regarderais à la mano les amenity=swimming_pool qui sont aussi />/leisure=*/

et puisque tu es partant pour le reste, que moi je considère bcp plus
risqué, et bien ça se complète pas trop mal

Je ne ferai ça pas avant qq jours.
Allez à plus
Paul

PS: à nouveau je suis obligé de copier-coller depuis archive

ce mail que je n'ai pas reçu directement

Le 22/10/2018 à , marc marc a écrit :

J'ai changé le titre pour bien montrer que je me focalisait
sur qu'un des points du problème plus général signalé par Noémie :
changer le tag déprécié amenity=swimming_pool car c'est
le problème le + gros en taille qu'elle a identifié.

je laisse l'autre sujet pour le reste pour éviter la noyade :)

Le 20. 10. 18 à 15:24, Paul Desgranges a écrit :

/ça devient un peu compliqué de discuter du reste />

Je pense que cette phrase résume aussi bien ma pensée.
Faire des étapes pour parfois 3 cas, c'est se compliquer la vie !
Je les ai corrigé, c'est plus rapide et simple.
Surtout qu'ils étaient déjà exclu du périmètre
de l'opération de masse.

/comment avais-tu compté ? />

avec overpass mais de manière cumulative (tag déprécié -A -B)
c'est pour cela que le détail intermédiaire n'est pas comparable.

/ne répondre qu'à une petite partie. />

je pensais n'avoir rien d’intéressant à dire sur le reste :)
Mais si tu insistes pour avoir mon avis, l'expérience a encore
montré récemment avec maxspeed:type qu'une édition de masse
qui se disperse reste à l'état de discussion sans aboutir.
Voilà pourquoi je suis partisan d'étapes indépendantes et
ciblées plutôt qu'une méga-opération ultra imbriquée.

Mais tu es totalement libre d'être plus optimiste que moi et
de mettre en place un tel plan, obtenir l'accord unanime que
nécessite une opération de masse, le documenter et l'effectuer.

/traiter tous ces cas spéciaux />>/Pas forcément à la main />>/Si tu es
d'accord avec ça /

non, je ne suis ni candidat ni d'accord pour faire des éditions
de masses avec les 244 cas restant basée sur des suppositions
(taux d'erreur trop élevé <> temps raisonnable pour regarder
cela individuellement).
J'en ai traité quelques centaines, dans les différentes catégories,
il n'y avait jamais une conclusion binaire à en tirer.

/avant de toucher aux 7000 qui restent, il faudra aviser à nouveau /
ok, j'attends que tu ai avisé :-)

Cordialement,
Marc

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

Was spricht denn grundsätzlich dagegen, Flächen mit way's zwischen zwei 
Flächen tatsächlich einfach nur als Verkehrsfläche zu mappen? Was gibts 
denn grundsätzlich, Pflanzenbewuchs, der gelegentlich weggemäht wird, 
also irgendwas mit Gras oder eben irgendeine künstliche, feste, 
verdichtete Oberfläche. Damit habe ich zum einen die nicht gemappte 
Straßenfläche, als auch Straßenbegleitgrün, als auch Randstreifen, 
Straßengraben, Schutzplanken (die in aller Regel neben der Fahrbahn 
stehen), etc. pp. zumindest mit einem entsprechenden "Raum" versorgt, 
innerhalb dessen sie zu finden sind.


Wie wir schon richtigerweise festgestellt haben, gehört der 
Straßengraben in seiner kompletten Breite zur Straße und ist Bestandteil 
dieser.


Dieses Szenario könnte für jede Art von Verkehrsfläche angewandt werden, 
die keine besondere Eigenschaft, wie bspw. "Parkplatz" hat. Also nicht 
nur auf den reinen Straßenverkehr bezogen, sondern Fläche zwischen 
Gleisen auf einem Bahnhof (so dort kein Bahnsteig ist, 
Güterbahnhofsfläche, Gleisbett, irgendwas) bspw. Rollfeld, Hafen - 
Flächen innerhalb derer verschiedenste way's verlaufen, Mauern, Bäume, 
weis der Geier was noch alles stehen und existieren kann. Selbst ein 
Gebäude kann innerhalb dieser "Verkehrsfläche" zu finden sein (bspw. das 
Wartehäuschen eines Busbahnhofes) Verkehrsinseln bei großen Kreuzungen,m 
etc. etc. etc. - mit dieser Fläche habe ich zuallererst mal den nötigen 
Platz geschaffen, innerhalb derer way's verlaufen um dem way als Linie 
den nötigen Raum zur richtigen Darstellung zu geben.


Gruß Sepp



Am 22.10.2018 16:49 schrieb Markus:

Hi Martin,

Als Ursache für diese Konflikte sehe ich folgende Ursachen:
a) die einen wollen "hübsche" Karten (nahtlos),
   die anderen wollen unaufwändig verbessern können
b) Missverständnisse aus Begriffsverwirrung (unklare Definitionen)

Wenn man "hübsch" will, sind gemeinsame Punkte wesentlich.
Wenn man iterative Verbesserung will, ist "unaufwändig verbessern
können" wesentlich.

Da in niedrigen Zoomleveln kein Unterschied erkennbar ist, und Lage und
Form nur in hohen Zoomleveln verbesserbar sind, würde ich der
Verbesserung höhere Priorität einräumen.

Und das mit den Missverständnissen - da müssen wir halt noch viel
präzisere und verständliche nachvollziehbare Beschreibungen schaffen.


Spundwand (Vertikale, feste, gebaute Uferbefestigung),
die begrenzt die Wasserfläche,


Ja, aber nur von oben (Senkrechtbild) betrachtet.
Im Aufriss liegt die Wiese je nach Wasserstand deutlich über dem Wasser
und getrennt davon, oder das Wasser bedeckt die Wiese.
Nur im seltenen Spezialfall stossen beide aneinander.

Wen nun in Florians Beispiel die "Kühe Wasser trinken", dann stehen sie
entweder im Überschwemmungsgebiet, oder sie haben sich am Ufer einen
Schlammhang gebaut, über den sie bis zum Wasser runterlaufen, oder sie
haben zu Giraffen mutiert ;-)

Das mit den Schlammlöchern ist häufig.
Dan hilft es aber sehr, wenn man beim Nacharbeiten einfach die Wiese
etwas wegziehen, und die Lücke passend taggen kann.

zwischen ihr und dem Wasser noch eine Spalt freizulassen wäre 
"falsch".


"richtig" wäre, wenn die Punkte "virtuell aufeinanderliegen",
datentechnisch (und im Renderer) nicht verbunden wären.

Damit es virtuell "keine Lücken" gibt,
aber man das Fehlende unkompliziert real "in die Lücke einfügen" kann 
;-)


bei fließenden Übergängen ist die Sache unklar, auch wie man es am 
besten
mappen soll, ich würde mich in der Diskussion hier zunächst auf die 
klaren

Fälle beschränken, wo die Grenzen klar erkennbar sind


Einverstanden.
Aber dazu muss man gaanz genau definieren und erklären.

Alternativ könnte man regeln: "keine gemeinsame Knoten".
Und es dem Renderer überlassen, wie er mit "virtuellen Lücken" umgeht.


weil es auch dort unterschiedliche Meinungen gibt,
wie man es abbilden will


Das liegt meist daran, dass jeder unter "es" etwas anderes versteht:


es sollte dort zumindest klar sein, was es ist, das man abbilden will


Das erfordert noch sehr viele erklärende konkrete Best-Practice-
Beispiele im Wiki!

(das Datenmodell erlaubt es von sich aus, klare Grenzen klar zu 
zeichnen).


Das Datenmodell erlaubt /ausschliesslich/ klare Grenzen.
Und solange es keine Darstellungsmethode für Diffuses gibt, bleibt
vermutlich ein systematisches unlösbares Problem.
(s. Spundwand, dort 3D-Prolem)


Friedhof der ohne Straße dazwischen an ein Wohngrundstück angrenzt

(Grenzmauer zwischen den beiden, typischerweise)


Jeder weiss, was ein "Friedhof" ist.
Aber was ist das datentechnisch genau?
- alles innerhalb der Gemarkungsgrenze?


falls das "Parzellengrenze" heissen sollte, nein (s.u.)


Die hierzulande im Grundbuch eingetragene Friedhofsgrenze.


- alles innerhalb der Aussenkante der Friedhofsmauer?


das ist vermutlich kulturell unterschiedlich, bei christlichen 
Friedhöfen
gibt es normalerweise (ja, gibt Ausnahmen), eine Mauer und das wäre 
für
mich die klare Grenze. Wenn ein Friedhof noch einen Parkplatz davor 
hat

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

Am Mo., 22. Okt. 2018 um 16:50 Uhr schrieb Markus :

> >> - alles innerhalb der Gemarkungsgrenze?
>   > falls das "Parzellengrenze" heissen sollte, nein (s.u.)
>
> Die hierzulande im Grundbuch eingetragene Friedhofsgrenze.
>
>
das sind die Parzellen bzw. Grundstücke (Gemarkung ist eher so was wie eine
Gemeinde).



> ...
> Dann sollte das so im Wiki stehen.
> Ebenfalls für Friedhofskapelle, Aussegnungshalle, Toiletten,
> Kompostlagerplatz, Friedhofsgärtnerei/-Blumenhandlung, etc.
>


im Prinzip ergibt sich das aus der Lage: wenn etwas innerhalb des
umfriedeten ( ;-) ) Bereichs ist, gehört es zum Friedhof, sonst nicht, d.h.
als Mapper muss man da nichts beachten, nur das Mappen was man sieht.



> Und natürlich: was wann wie mit was verbunden sein soll oder nicht - und
> warum in welchem Fall ;-)
>


die Regeln sind immer gleich: wenn es dieselbe Grenze/Linie/way ist, dann
sollten man auch denselben way verwenden, sonst nicht.



>
> >> - was ist, wenn die Friedhofsmauer (teilweise) gleichzeitig die
> >>   Stadtmauer ist? was gehört dann zu "residental" bzw. "graveyard"?
> >
> > alles bis Innenkante Stadtmauer würde ich sagen, ausser in der Mauer ist
> > auch noch Begräbnisstätte.
>
> Das meine ich mit "Genauigkeit in der Beschreibung":
> ich meinte, der Friedhof ist aussen die Stadt ist innerhalb der
> gemeinsamen Mauer (hatte ich aber nicht dazugeschrieben).
>


ach so, hast Du dazu mal ein reales Beispiel?



> Du meintest vermutlich: dass beides innerhalb der Stadtmauer ist?
>


ja, s. mein Beispiel (sind sogar 3 Friedhöfe nebeneinander und an der
Stadtmauer) ;-)



>>  - alles innerhalb das für Gräber vorgesehen ist?
> >>(also nicht der Wald, nicht die Gebäude, nicht der Teich)
> >> - nur die für Gräber vorgesehene Fläche (ohne Zufahrtswege)?
> >> - nur die für Gräber vorgesehene Fläche (ohne alle Wege)?
> >> - nur die für Gräber aktuell genutzte Fläche?
> >
> > nein
>
> Dann muss das genau so ins Wiki :-)
> (sonst wird das - und anderes - noch ewig diskutiert)
>


naja, m.E. sollte ins Wiki das, was etwas _ist_, nicht was es _nicht ist_,
weil diese Liste wird potentiell unendlich lang.



>
> Die am Haus L-förmig angebaute Garage - wann ist das nun:
> - ein Haus mit einem Umriss und 7 Punkten
> - ein Haus mit einem Umriss und Trennwand, insgesamt 7 Punkten
> - zwei Häuser mit insgesamt 7 Punkten, 2 davon verbunden
> - zwei Häuser mit je 4 Punkten
> Und was ändert sich, wenn später über der Garage ein Dachgeschoss gebaut
> und dieses mit dem Haupthaus integrierend verbunden wird.
>


m.E. ist das am Einfachsten als 2 Gebäude abzubilden, und könnte das auch
nach dem Umbau bleiben. Sonst könnte man wahrscheinlich auch ein Gebäude
und building:parts machen (bei Garagen tendiere ich eher zu eigenem
Gebäude). Was genau ein Gebäude und was nur ein part ist, das muss in OSM
auch weitgehend unscharf bleiben, weil wir gar nicht genug Kenntnisse davon
haben, wie das Gebäude funktioniert und gebaut ist. Eine Garage ist ein
Raum der als Fahrzeugstellplatz (unter anderem) vorgesehen ist, das kann
aber vom notdürftig umschlossenen Raum unter einem leichten Dach
(allerdings wohl nicht nach deutschen Normen) bis zu einem vollwertigen
Raum nach sonstigem Gebäudestandard alles sein, kommt also drauf an.


> ja, das sind unterschiedliche Dinge, aber es ändert nichts daran dass ihre
> > Geometrie voneinander abhängt: die Gebäudekante ist gleichzeitig die
> > Platzkante. Das ist dieselbe Linie. Dazwischen ist nichts.
>
> Je nachdem...
> Es gibt Häuser, deren Dach über den Platzrand ragt, aber die Autos
> trotzdem bis zur Hauswand parken dürfen. Andere haben einen "Vorgarten".
> Und manchmal ist das kaum unterscheidbar ;-)
>


ja, wenn es einen Vorgarten gäbe, dann wäre der Platz evtl. dort zu Ende
(normalerweise würde ich dann aber dort auch eine Mauer oder einen Zaun
erwarten, gibt aber natürlich alles, wollte mit dem Platz nur ein typisches
Beispiel suchen, wo man sich ein gemeinsames Bild machen kann, d.h. in dem
Beispiel gibt es dort keine Mauer oder Vorgarten sondern der Platz reicht
bis an die Aussenkante der Randbebauung).

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

2018-10-22 Per discussione Frederik Ramm

Hallo,

On 10/22/18 11:27, Christoph Hormann wrote:
> Ich sehe ein gewisses Problem bei der Regel 2 in dem Fall, dass es 
> grundsätzlich als korrekt angesehen wird, wenn die Linie über die 
> Fläche gezeichnet wird - was zumindest bei kleineren Straßen und Tracks 
> im Wald allgemein anerkannt ist.  Da wir gleichzeitig die etablierte 
> Regel haben, dass Waldflächen und ähnliches in kleine, handhabbare und 
> ggf. ohne Multipolygone mapbare Stücke aufgeteilt werden können und 
> sollten, würde diese Regel im Grunde bedeuten: Man darf aufteilen, aber 
> niemals entlang einer Straße.  Das wäre dann ein bisschen schräg.

Man könnte das ja auch als oneway-Regel ähnlich wie das mit der groben
Ersterfassung formulieren:

1. Du kannst eine Straße quer durch einen Wald malen.

2. Du kannst den Wald auch entlang der Straße - mit Verkleben - in zwei
Teile teilen.

3. Wenn dann jemand kommt und das schön entklebt, ist das ok.

4. Du kannst niemals einen entklebten Wald entlang einer Straße wieder
verkleben.

Bye
Frederik

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

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

2018-10-22 Per discussione Markus

Hallo Christian,

> das Datenmodell stärker axiomatisieren 

vs.

> Dafür zu werben, dass etwas, das technisch funktioniert
> nicht genutzt werden soll, das nach Maßgabe der Inter-
> pretation anderer Mitwirkender nicht IMMER falsch ist,
> kann nur ein Kampf gegen Windmühlen sein.

Ich verstehe Letzteres als Argumentieren, um gemeinsam Ziele zu
vereinbaren und dazu passende Methoden zu finden.

Ersteres empfinde ich aber eher hierarchisch.
Und für die Gemeinschaft gute Leitfiguren sind heutzutage eher selten.

Letzteres ist aufwändig und setzt Achtsamkeit und Wertschätzung voraus.
Und vielleicht bedarf es in offenen und freien Communities besonderer
Methoden um dabei erfolgreich zu sein.

Aber das wäre nun eine Meta-Meta-Aufgabe...
Lohnend - nicht nur für OSM.

Mit herzlichem Gruss,
Markus

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

Re: [OSM-talk] Fwd: DWG policy on Crimea

2018-10-22 Per discussione Colin Smale

On 2018-10-22 16:34, Mateusz Konieczny wrote:

> I strongly disagree, we map reality.

There is no one true reality, only perceptions. Which reality takes
precedence in your mind, may not be the same for everyone. Reality is
subjective. 

What is the test to apply to decide whether a point is included in
country A or country B? Is it who empties the rubbish bins perhaps? Is
it where the taxes are paid to? Is it what an arbitrary local would
answer to the question "what country are you in?" Putting it in
objective terms, and then applying the criteria consistently,
facilitates getting consensus. 

In the case of disputed borders, there are at least two realities (as
perceived by the parties to the dispute) and possibly a third reality as
perceived by a number of locals - who need to give objective answers to
carefully selected questions so that unintended bias is avoided.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

Amen.  Das ist halt deine Meinung.
Aber die ist so fest wie sie fester
nicht sein kann!?

Wiederholend, was schon gesagt war:
Es hängt eben davon ab, wie die Daten durch
das Modell repräsentiert werden.  Solange eine
(Mittel-)Linie ein flächenhaftes Objekt _ge-
neralisiert_, solange besteht eben auch die
Möglichkeit, sie in bestimmte Beziehungen zu
anderen flächenhaften Objekten zu setzen,
die unter Berücksichtigung der jew. gültigen
Interpretation alle Sinn ergeben und "richtig"
sind.

Wenn das alles so wäre, wie du es dir vorstellst,
und also generell, total, absolut und jederzeit
falsch ist und ein Verkleben also tatsächlich sach-
unbezogen und damit allgemeingültig falsch ist,
warum hast du dann nicht längst den Universal-Patch
für das Problem geschrieben, der programmatisch einen
Upload der in deinen Augen falschen Topologien ver-
hindert?

Es ist wiederholt gesagt sinnlos, das weiter zu
diskutieren, solange das Datenmodell definitorisch
offen für mehrere Interpretationen ist.  Was du be-
klagst, ist diese Offenheit:  Du hättest keinen Grund
zur Klage, wenn programmatisch ein Verbot bestünde,
die von dir monierten Geometrien überhaupt erst hoch-
zuladen (d.h. Prüfung bei Upload in die DB).  Allein
das dies in den letzten Jahren nicht geschehen ist,
zeigt doch, dass deine Meinung offenbar nicht in so-
weit geteilt wird, dass sie für ein von Konsens ge-
tragenem Verbot ausreicht!?

Der Grad der Perfektion, den du anstrebst, ist doch
ganz offenbar leichter erreichbar, wenn die deiner
Meinung nach falschen Geometrien gar nicht erst hoch-
ladbar sind.  Um dieses Ziel zu verfolgen könnte man
m.E. das Datenmodell stärker axiomatisieren und insbes.
Vorgaben machen, wie bestimmte Grade der Generalisierung
geographischer Features interagieren dürfen.

Dafür zu werben, dass etwas, das technisch funktioniert
nicht genutzt werden soll, das nach Maßgabe der Inter-
pretation anderer Mitwirkender nicht IMMER falsch ist,
kann nur ein Kampf gegen Windmühlen sein.

Jedes Beitragen von Daten in OSM ist fehlerbehaftet, vor-
sätzlich und generalisierend!  Solche Plattitüden bringen
dich m.E. nicht weiter.  Wenn du an der Gesamtsituation
etwas ändern und für bestimmte Datenlagen Verbote auf-
stellen willst, kannst du die m.E. nur sinnvoll mit soft-
wareseitigen Umstellungen durchsetzen.  Da ich nicht die
Mehrheit bin, eine solche Umstellung in OSM aber mehr-
heitsfähig sein müsste, ist es eigentlich unerheblich ob
du meine Stimme für ein solches Unterfangen bekommst und
ob, wann, wo und wie ich Daten ver- oder entklebe.

Gruß

> On Mon, Oct 22, 2018 at 03:28:59PM +0200, "Christian Müller" wrote:
> 
> Verkleben ist das vorsätzliche hinzufügen von Fehlern zum zwecke
> der Generalisierung.
> 
> Flo

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

2018-10-22 Per discussione Markus

Hi Martin,

Als Ursache für diese Konflikte sehe ich folgende Ursachen:
a) die einen wollen "hübsche" Karten (nahtlos),
   die anderen wollen unaufwändig verbessern können
b) Missverständnisse aus Begriffsverwirrung (unklare Definitionen)

Wenn man "hübsch" will, sind gemeinsame Punkte wesentlich.
Wenn man iterative Verbesserung will, ist "unaufwändig verbessern
können" wesentlich.

Da in niedrigen Zoomleveln kein Unterschied erkennbar ist, und Lage und
Form nur in hohen Zoomleveln verbesserbar sind, würde ich der
Verbesserung höhere Priorität einräumen.

Und das mit den Missverständnissen - da müssen wir halt noch viel
präzisere und verständliche nachvollziehbare Beschreibungen schaffen.

> Spundwand (Vertikale, feste, gebaute Uferbefestigung),
> die begrenzt die Wasserfläche, 

Ja, aber nur von oben (Senkrechtbild) betrachtet.
Im Aufriss liegt die Wiese je nach Wasserstand deutlich über dem Wasser
und getrennt davon, oder das Wasser bedeckt die Wiese.
Nur im seltenen Spezialfall stossen beide aneinander.

Wen nun in Florians Beispiel die "Kühe Wasser trinken", dann stehen sie
entweder im Überschwemmungsgebiet, oder sie haben sich am Ufer einen
Schlammhang gebaut, über den sie bis zum Wasser runterlaufen, oder sie
haben zu Giraffen mutiert ;-)

Das mit den Schlammlöchern ist häufig.
Dan hilft es aber sehr, wenn man beim Nacharbeiten einfach die Wiese
etwas wegziehen, und die Lücke passend taggen kann.

> zwischen ihr und dem Wasser noch eine Spalt freizulassen wäre "falsch".

"richtig" wäre, wenn die Punkte "virtuell aufeinanderliegen",
datentechnisch (und im Renderer) nicht verbunden wären.

Damit es virtuell "keine Lücken" gibt,
aber man das Fehlende unkompliziert real "in die Lücke einfügen" kann ;-)

> bei fließenden Übergängen ist die Sache unklar, auch wie man es am besten
> mappen soll, ich würde mich in der Diskussion hier zunächst auf die klaren
> Fälle beschränken, wo die Grenzen klar erkennbar sind

Einverstanden.
Aber dazu muss man gaanz genau definieren und erklären.

Alternativ könnte man regeln: "keine gemeinsame Knoten".
Und es dem Renderer überlassen, wie er mit "virtuellen Lücken" umgeht.

> weil es auch dort unterschiedliche Meinungen gibt,
> wie man es abbilden will

Das liegt meist daran, dass jeder unter "es" etwas anderes versteht:

> es sollte dort zumindest klar sein, was es ist, das man abbilden will 

Das erfordert noch sehr viele erklärende konkrete Best-Practice-
Beispiele im Wiki!

> (das Datenmodell erlaubt es von sich aus, klare Grenzen klar zu zeichnen).

Das Datenmodell erlaubt /ausschliesslich/ klare Grenzen.
Und solange es keine Darstellungsmethode für Diffuses gibt, bleibt
vermutlich ein systematisches unlösbares Problem.
(s. Spundwand, dort 3D-Prolem)

>> Friedhof der ohne Straße dazwischen an ein Wohngrundstück angrenzt
>>> (Grenzmauer zwischen den beiden, typischerweise)
>>
>> Jeder weiss, was ein "Friedhof" ist.
>> Aber was ist das datentechnisch genau?
>> - alles innerhalb der Gemarkungsgrenze?
> 
> falls das "Parzellengrenze" heissen sollte, nein (s.u.)

Die hierzulande im Grundbuch eingetragene Friedhofsgrenze.

>> - alles innerhalb der Aussenkante der Friedhofsmauer?
> 
> das ist vermutlich kulturell unterschiedlich, bei christlichen Friedhöfen
> gibt es normalerweise (ja, gibt Ausnahmen), eine Mauer und das wäre für
> mich die klare Grenze. Wenn ein Friedhof noch einen Parkplatz davor hat
> (grundstückstechnisch), würde ich den eher nicht zum Friedhof schlagen
> sondern für sich mappen. 

Dann sollte das so im Wiki stehen.
Ebenfalls für Friedhofskapelle, Aussegnungshalle, Toiletten,
Kompostlagerplatz, Friedhofsgärtnerei/-Blumenhandlung, etc.
Und natürlich: was wann wie mit was verbunden sein soll oder nicht - und
warum in welchem Fall ;-)

Die Mauer müsste schon sehr dick sein, dass Innen-
> und Aussengrenze verschiedene Objekte wären.
> Z.B. gibt es hier einen Friedhof an der Stadtmauer, das ist bisher immer
> noch die Mauer als nur eine Linie gemappt (könnte man aber zugegebenermaßen
> bei Gelegenheit mal nachholen): https://www.openstreetmap.org/way/24575663

Ja, da fehlt noch Vieles im und um den Friedhof ;-)

>> - was ist, wenn die Friedhofsmauer (teilweise) gleichzeitig die
>>   Stadtmauer ist? was gehört dann zu "residental" bzw. "graveyard"?
> 
> alles bis Innenkante Stadtmauer würde ich sagen, ausser in der Mauer ist
> auch noch Begräbnisstätte.

Das meine ich mit "Genauigkeit in der Beschreibung":
ich meinte, der Friedhof ist aussen die Stadt ist innerhalb der
gemeinsamen Mauer (hatte ich aber nicht dazugeschrieben).
Du meintest vermutlich: dass beides innerhalb der Stadtmauer ist?
Und Gräber (oder Urnen) /in/ der Mauer machen sowieso alles noch
schwieriger.

>> - wann liegt der Friedhof "im Wald"?
>>   wann liegt der Wald "im Friedhof"?
>>   wann sind es gleichrangige Objekte?
> 
> ist z.B. eine Frage der Größen

Nein, das ist eine Frage der Definition:

> jedenfalls kann das mit unseren Daten jeder für sich entscheiden.

Dabei legt er (s)eine

[talk-ph] OSM Road Network Enhancement Efforts In Cebu

2018-10-22 Per discussione grab osm

Hello All,

We would start reviewing the road network in the entire city of Cebu
Scope involved will be only road network - Map missing roads and correct
existing network with reference to tags and classifications as appropriate

Basis the pre-analysis we did to identify the right imagery and offsets, we
found that ESRI is the imagery used with existing strava offset
We will use ESRI as default imagery with appropriate offset distance -
existing or newly created basis strava.
We will also use other images to ensure there are no missing roads.

While we follow the standard OSM mapping guidelines, please suggest for any
country specific policies that needs to referred

We have created a new issue in our project page.  For any questions and/or
feedback, please let us know
https://github.com/GRABOSM/Grab-Data/issues/26

Thanks
Grab Team
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [OSM-talk] Fwd: DWG policy on Crimea

22. Oct 2018 15:51 by yuriastrak...@gmail.com :

> On Mon, Oct 22, 2018 at 8:22 AM Mateusz Konieczny <> matkoni...@tutanota.com 
> > > wrote:
>
>>   
>>> I think a country relation should describe how the specific country think 
>>> of its borders. So if two countries claim the same territory, those two 
>>> relations will overlap.
>>
>> That is absurd and conflict with OSM rule to map what exists. 
>>
>>
> On the contrary, it actually matches OSM rules better than deciding yourself. 
>  When drawing a city outline, you go to that city's government, and get the 
> geoshape from them. 

> By extension, if you draw a country, you should use that country's 
> definition.  

I strongly disagree, we map reality. When I map a business I map what exists 
there, not

what the owner claims to be existing. When I map road I map what exists not 
what is

supposed to exist there according to official sources.

When I map the border of a country I map line of control, not an official claim 
of the country.

Maybe "officially claimed border of country" is also mappable but it would not 
be marked as

a border.

> By extension, if you draw a country, you should use that country's 
> definition.  

I also disagree as for when it comes to making maps. I see no reason why I 
should be

obligated by official claims by specific country. I may follow them in some 
cases but

it is often undesirable or harmful.

> If two country's definitions happen to overlap, we ought to document both.

I am not sure whatever we should map border claims.

>>> So when I generate a map for Russia, I have to show Crimea as part of 
>>> Russia.  For Ukraine - as part of Ukraine.  Same for China and India and ...
>>
>> There are also other sources of data. For example to show proper terrain 
>> shape or to show ratings of restaurants and for many others use cases OSM is 
>> not sufficient.
>>
> The argument "it doesn't work for X, therefor we shouldn't make it work for 
> Y" is puzzling.

No, I was just reminding that OSM is not for all and every geographical data.

I am not sure whatever border claims are one of these cases.

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

Re: [OSM-talk] Fwd: DWG policy on Crimea


22. Oct 2018 16:17 by dieterdre...@gmail.com :


> Am Mo., 22. Okt. 2018 um 15:54 Uhr schrieb Yuri Astrakhan <> 
> yuriastrak...@gmail.com > >:
>
>> On Mon, Oct 22, 2018 at 8:22 AM Mateusz Konieczny <>> 
>> matkoni...@tutanota.com >> > wrote:
>>
>>>   
 I think a country relation should describe how the specific country think 
 of its borders. So if two countries claim the same territory, those two 
 relations will overlap.
>>>
>>> That is absurd and conflict with OSM rule to map what exists. 
>>>
>>>
>> On the contrary, it actually matches OSM rules better than deciding 
>> yourself.  When drawing a city outline, you go to that city's government, 
>> and get the geoshape from them. By extension, if you draw a country, you 
>> should use that country's definition.  If two country's definitions happen 
>> to overlap, we ought to document both.
>
>
> In principle I agree it would be desirable to keep records of "all" claims 
> for a territory, (I can imagine there will be some more rules required, 
> because there are even small groups and individuals claiming authority over 
> territories with very low possibility to be recognized by anyone else, and we 
> might want to exclude those "trolls"). But this should not mean that we do 
> not keep information about who actually controls the territory, and who has 
> claims on it but does not control it. Simply adding a territory to 2 
> countries at the same time can't be the solution.




I am not fundamentally opposed to adding various claims to OSM (though I am not

supporting it either).




But in cases where there is clear who controls given territory main border then 


main administrative boundary should be applied to line of control. 

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

Re: [Talk-it] quartiere

2018-10-22 Per discussione Gabriele Sani

Ho trovato lo statuto del quartierei, mappati i confini e riattivato il
tutto

Grazie ancora

Il giorno lun 22 ott 2018 alle ore 15:53 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

>
>
> Am Mo., 22. Okt. 2018 um 15:46 Uhr schrieb Gabriele Sani <
> gabryatfen...@gmail.com>:
>
>> Grazie per la risposta.
>> Il problema e' proprio quello: intuisco quali sono i confini da
>> conoscenze personali, ma non ho ancora trovato una fonte ufficiale.
>> Si', aveva "inglobato" tutto perche' non aveva boundaries, e penso che
>> finche' non vengano stabiliti quelli esatti sia meglio rimuovere il punto
>> (mi sbaglio?)
>>
>>
> quando i place sono mappati solo come nodi, chi usa i dati deve indovinare
> quanto possono essere grandi.
> Invece quando abbiamo mappato il place come area diventa chiaro.
>
>
>
>
>> Appena trovo una fonte ufficiale lo rimetto
>>
>
>
> assolutamente no, lo puoi rimettere già ora. Non ci importa della fonte
> ufficiale, sopratutto se si tratta di un place=neighbourhood ci potrebbe
> anche non essere. In OSM li puoi inserire proprio come hai scritto sopra: "
> intuisco quali sono i confini da conoscenze personali,...". Le conoscenze
> personali hanno maggior valore in OpenStreetMap.
>
> Ciao,
> Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-ie] Collinstown Townland has been re mapped as Dublin Airport!

2018-10-22 Per discussione Patrick Matthews

Looking around last night, something similar seems to have been done at the
Belgard quarry on the south side of Dublin and looking at the relevant
relation history it seems to be the same few names who are involved in
freelance boundary redrawing in both locations. I'm sure there may be other
places where this has gone on but that was the one that I noticed.

Paddy Matthews.

On Sun, Oct 21, 2018 at 12:29 PM Brian Hollinshead 
wrote:

> While adding the Malahide Union of parishes to the map which uses a
> combination of the old civil parish boundaries I find that Collinstown
> townland (relation/5436241) has been seriously redrawn if compared to the
> GSGS 3906 map and maps.openstreetmap.ie. Rorys townlands.ie shows the post
> changes state.
> It looks as thought someone thought Collinstown Airport was the new
> townland.
>
> The border between townland of Forrest Little(relation 5440762) and
> Clonshaugh, Corballis and Huntstown has been quite altered between
> 53.435847/-6.236136 and 53.4316541/-6.2644.
>
> I believe this also alters some Barony and Superintendent Registrars
> District boundaries so feel it is highly preferable that these changes be
> reversed intact.
>
> I regret this is way above my capability so I ask for someone reading this
> to please address this issue.
>
> Thank you for your kindness.
>
> By the way, Many thanks to those organised such an enthusiastic meeting in
> Maynooth yesterday, the future looks good.
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [OSM-talk] Fwd: DWG policy on Crimea

Am Mo., 22. Okt. 2018 um 15:54 Uhr schrieb Yuri Astrakhan <
yuriastrak...@gmail.com>:

> On Mon, Oct 22, 2018 at 8:22 AM Mateusz Konieczny 
> wrote:
>
>> I think a country relation should describe how the specific country think
>> of its borders. So if two countries claim the same territory, those two
>> relations will overlap.
>>
>> That is absurd and conflict with OSM rule to map what exists.
>>
> On the contrary, it actually matches OSM rules better than deciding
> yourself.  When drawing a city outline, you go to that city's government,
> and get the geoshape from them. By extension, if you draw a country, you
> should use that country's definition.  If two country's definitions happen
> to overlap, we ought to document both.
>

In principle I agree it would be desirable to keep records of "all" claims
for a territory, (I can imagine there will be some more rules required,
because there are even small groups and individuals claiming authority over
territories with very low possibility to be recognized by anyone else, and
we might want to exclude those "trolls"). But this should not mean that we
do not keep information about who actually controls the territory, and who
has claims on it but does not control it. Simply adding a territory to 2
countries at the same time can't be the solution.

The complicated part seems to state whose version of the country/border it
is. We could have multiple countries for the different possibilities with a
tag (or memberships) that says from which country this is (e.g. for the
Crimea we would have the borders of Russia and of Ucraine according to the
Ucraine and to Russia = 4 versions of the 2 countries). But when those
countries have different disputes with different other countries, this
could become very complex and unmaintainable.

Not sure how to encode for members of a (country)relation that they are the
view of a specific country. Maybe it could be achieved with another
relation type. Border ways could go into border relations (one or more
connected ways) that are part of a border and have tags which say who has
recognized them or whose view it is (this could also be done with a role
like "according_to" and the country as a member, or a simple tag like
according_to=CN). The country relation would be built by referring to those
border relations (it would contain all borders and alternative borders, and
the parts would have the tag that says according to whom).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: DWG policy on Crimea

2018-10-22 Per discussione Yuri Astrakhan

On Mon, Oct 22, 2018 at 8:22 AM Mateusz Konieczny 
wrote:

> I think a country relation should describe how the specific country think
> of its borders. So if two countries claim the same territory, those two
> relations will overlap.
>
> That is absurd and conflict with OSM rule to map what exists.
>
On the contrary, it actually matches OSM rules better than deciding
yourself.  When drawing a city outline, you go to that city's government,
and get the geoshape from them. By extension, if you draw a country, you
should use that country's definition.  If two country's definitions happen
to overlap, we ought to document both.

> E.g. it would be illegal in some countries to generate political map not
> according to that country's government.
>
> It is also against Chinese law to publish accurate maps of China. It is
> not a sufficient reason to forbid accurate mapping of China in OSM.
>
I did not say we must abide by laws of every country - would not be
possible in case of conflicts. I only said that some countries require you
to draw maps according to their laws.  China is clearly a special case
here, but other countries are much more reasonable, yet still expect you to
draw their maps for them according to their rules.

> So when I generate a map for Russia, I have to show Crimea as part of
> Russia.  For Ukraine - as part of Ukraine.  Same for China and India and ...
>
> There are also other sources of data. For example to show proper terrain
> shape or to show ratings of restaurants and for many others use cases OSM
> is not sufficient.
>
The argument "it doesn't work for X, therefor we shouldn't make it work for
Y" is puzzling. We can easily make it work for the very practical usecase I
outlined -- drawing countries' borders based on the expectations of a
specific user's location.  Country borders are by definition a
controversial topic without a single answer, and as you said, there are
other data sources for it. Yet we add it to OSM because it has a very
tangible value to the data consumers (who don't have to mix-in multiple
data sources for the basic mapping needs).
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] quartiere

Am Mo., 22. Okt. 2018 um 15:46 Uhr schrieb Gabriele Sani <
gabryatfen...@gmail.com>:

> Grazie per la risposta.
> Il problema e' proprio quello: intuisco quali sono i confini da conoscenze
> personali, ma non ho ancora trovato una fonte ufficiale.
> Si', aveva "inglobato" tutto perche' non aveva boundaries, e penso che
> finche' non vengano stabiliti quelli esatti sia meglio rimuovere il punto
> (mi sbaglio?)
>
>
quando i place sono mappati solo come nodi, chi usa i dati deve indovinare
quanto possono essere grandi.
Invece quando abbiamo mappato il place come area diventa chiaro.




> Appena trovo una fonte ufficiale lo rimetto
>


assolutamente no, lo puoi rimettere già ora. Non ci importa della fonte
ufficiale, sopratutto se si tratta di un place=neighbourhood ci potrebbe
anche non essere. In OSM li puoi inserire proprio come hai scritto sopra: "
intuisco quali sono i confini da conoscenze personali,...". Le conoscenze
personali hanno maggior valore in OpenStreetMap.

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

Re: [OSM-talk-fr] Ces collectivités qui misent sur Openstreetmap et la cartographie participative

2018-10-22 Per discussione Vincent Bergeot


Le 22/10/2018 à 12:00, François Lacombe a écrit :
C'est une très bonne chose que les collectivités se saisissent de cet 
outil et nous mettent en lumière par ailleurs.


En parlant de mettre en lumière, la 1ere phrase est un peu étonnante. 
Elle installe la confusion.


je suis assez d'accord sur le mélange entre cartopartie, OpenStreetMap, 
la cartographie participative.


Il me semble qu'il y a des confusions entre l'utilisation de rendus 
cartographiques OSM, l'ajout de données dans OSM, la création de données 
projetés sur des fonds OSM.


Un exemple / Pour avoir échangé un peu sur la question de l'allier, il y 
est surtout question de créer des données mais pas forcément de les 
intégrer à OSM et/ou les mettre à disposition. Ainsi ce site pour 
améliorer leur base 
http://www.allier.fr/523-observatoire-des-services-au-public.htm


Pour trouver les données par contre c'est autre chose. Il y a 
aujourd'hui ceci 
https://www.data.gouv.fr/fr/datasets/distributeurs-automatiques-de-billets-dab/ 
mais le reste !!!
Et même si on peut saluer la LO sur ce jeu de données, il est dommage 
que cela n'ait pas été directement intégré à OSM (cela signifie un 
second boulot par exemple avec Osmose, que d'énergie "perdue"). Et quand 
aux autres jeux de données, un jour peut-être ?



Depuis le début de l'histoire, c'est nous qui proposons aux 
collectivités de mieux connaître leur territoire, en collectant des 
données locales et en dépensant beaucoup d'énergie pour être considérés.
Même si ce n'est certainement pas politiquement correct voire tiré par 
les cheveux ici, je serais bien vigilent à ce qu'ils ne retournent pas 
les choses en leur faveur :)
C'est la communauté des citoyens qui produit une base de données de 
qualité, et les collectivités comme la plupart des acteurs publics 
sont bien à la traîne. Pas l'inverse, ce qu'on pourrait comprendre en 
lisant l'article.


il me semble surtout que l'on doit arriver à trouver le bon degré de 
discussion car oui OSM fournit une information de qualité mais les 
collectivités possèdent aussi des données de qualité et/ou des bonnes 
volontés pour avancer sur ces sujets. Ces collectivités ont souvent une 
histoire qui rend tout beaucoup plus lent, long c'est sur :)


Je suis cependant d'accord avec toi sur la vigilance à avoir sur leur 
capacité de récupération politique...


Sinon, l'article a également été repris sur le site de l'association 
OSM-fr https://www.openstreetmap.fr/collectivites-misent-openstreetmap/

Des compléments peuvent être apportés pour expliciter tout cela !!!

à plus


--
Vincent Bergeot


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

Re: [Talk-us] Spartanburg County SC road centerlines import

2018-10-22 Per discussione Richard Fairhurst

Mike N. wrote:
> As one who grew up in a rural area, a country road lined with 4 
> houses in a mile would feel "residential" and I would tend to set 
> it as residential in OSM.   That describes most of the rural parts 
> of this county also, except for roads that don't happen to have 
> a house.

Absolutely, not disputing that - it's simply that tiger:reviewed=no is a
good signifier that "the surface type on this road might not be what you'd
expect", and for developed countries that's traditionally a paved surface
for residential roads. As long as there's some way of discerning that, I'm
happy.

cheers
Richard

--
Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html

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

Re: [OSM-talk-fr] repère géodésique détruit

2018-10-22 Per discussione GarenKreiz

Tant que les bâtiments portant des points géodésiques détruits apparaissent
encore sur les orthophotos et le cadastre, il faudrait peut-être les garder
pour permettre la vérification de leur calage.

   GK


On Mon, 22 Oct 2018 at 14:44, François Lacombe 
wrote:

> Hello,
>
> Sur le même sujet, j'ai supprimé environ 150 pylônes RTE qui ont été
> démontés entre Charleville Mezieres et Reims hier soir.
> Certains avaient des points géodésiques que j'ai laissé.
> https://www.openstreetmap.org/node/669984935
>
> Mais ces points ont du disparaître, ou être déplacés consécutivement aux
> travaux sur place.
> Dois-je mettre un end_date ?
>
> François
>
> Le dim. 21 oct. 2018 à 21:54, marc marc  a
> écrit :
>
>> Le 21. 10. 18 à 21:49, Alain VASSAULT a écrit :
>> > tu as la ref du point geodesique ou ces coordonnées?
>>
>> il y les a 2, sur les 2 objets
>> https://www.openstreetmap.org/node/67945
>> https://www.openstreetmap.org/node/67946
>>
>> > jai l'appli "beta" librement dispo sur le google store
>> > pour consulter et report sur les fiches geodesique.
>>
>> Je suis curieux de voir ce que cela va donner, merci.
>>
>> > Le 21 octobre 2018 21:45:43 GMT+02:00, David Crochet
>> > a écrit :
>> >
>> > J'ai envoyé un message à l'adresse ad'hoc pour signaler la
>> disparition
>> > de la croix, avec photo d'un média audiovisuel  à l'appui :
>>
>> Merci, voyons voir leur réaction. au moins "osm" aura transmis :)
>>
>>  Message transféré 
>> Sujet : repère géodésique détruit
>> Date : Sun, 21 Oct 2018 20:29:10 +0200
>> De : Marc M. 
>> Pour : talk-fr 
>>
>> Bonjour,
>>
>> Un constructeur signale le démontage d'un clocher d'église qui
>> hébergeait 2 repères géodésiques.
>> https://www.openstreetmap.org/note/1563371
>> https://www.openstreetmap.org/node/67945
>> https://www.openstreetmap.org/node/67946
>> au niveau osm, c'est facile
>> was: devant le man_made=survey_point
>> un end_date
>> une maj de la description
>>
>> mais je demandais :
>> - il y a a-t-il un outil QA qui va crier pour sa disparition ?
>> Si oui quel schéma supporte-t-il ?
>> - quelqu'un est en contact avec l'ign pour leur remonter l'info
>> s'ils ne l'ont pas ?
>>
>> Cordialement,
>> Marc
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] quartiere

2018-10-22 Per discussione Gabriele Sani

Grazie per la risposta.
Il problema e' proprio quello: intuisco quali sono i confini da conoscenze
personali, ma non ho ancora trovato una fonte ufficiale.
Si', aveva "inglobato" tutto perche' non aveva boundaries, e penso che
finche' non vengano stabiliti quelli esatti sia meglio rimuovere il punto
(mi sbaglio?)

Appena trovo una fonte ufficiale lo rimetto

Grazie ancora

Il giorno lun 22 ott 2018 alle ore 15:42 Daniele Santini <
danysa...@gmail.com> ha scritto:

> ho appena scoperto e risolto un errore nella mia citta' dove un
>> neighborhood
>> aveva in qualche modo inglobato la citta' intera.
>
> Come si mappa correttamente un quartiere/zona di una citta'?
>>
>
> Cosa intendi con "aveva inglobato la città intera"?
> Se intendi che in tutta la città i risultati delle ricerche dicevano che
> il posto fosse in quel neighborhood, il problema non era il nodo in se ma
> il fatto che non avesse confini.
> Anche la pagina wiki di place=neighborhood [1] avverte del problema: "When
> tagged as node, all the sorrounding addresses refer to this node and the
> corresponding address is often wrong, expecially near borders. *Fix*:
> using area/relation to define the boundary".
> In questo caso la soluzione NON è eliminare il nodo ma è mappare i confini
> del neighborhood.
>
> Per mappare i confini prima di tutto devi creare i singoli segmenti di
> confine come way e taggarli con boundary=administrative+admin_level=10 .[2]
> Quindi devi creare una relazione  taggata
> type=boundary+boundary=administrative+admin_level=10 .[3]
> Infine devi aggiungere come membri della relazione tutti i segmenti con
> ruolo "outer" e il place=neighborhood con ruolo "admin_centre".
> Lo stesso discorso vale se invece di un place=neighborhood hai un
> place=suburb/quarter/...
>
> Se non conosci i confini esatti invece sei "in braghe di tela" perchè non
> c'è una soluzione (che io sappia).
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:place%3Dneighbourhood#Issues
> [2]
> https://wiki.openstreetmap.org/wiki/Tag:boundary=administrative#10_admin_level_values_for_specific_countries
> 
> [3] https://wiki.openstreetmap.org/wiki/Relation:boundary
> 
>
>> ___
> 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-cz] historic=tomb se nerenderuje na Mapniku

2018-10-22 Per discussione majka

Ze mě neznámého důvodu je rozdíl, jak funguje dotaz ve formě
area[name="Česko"];
[dotaz](area);

a ve formě
area[name="Česko"]->.searchArea;
[dotaz](area.searchArea);

Žila jsem v tom, že obojí má fungovat naprosto stejně, ale ten první dotaz
vrací jen body, žádné polygony. Netuší tu někdo, proč tomu tak je?
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-it] quartiere

2018-10-22 Per discussione Daniele Santini

>
> ho appena scoperto e risolto un errore nella mia citta' dove un
> neighborhood
> aveva in qualche modo inglobato la citta' intera.

Come si mappa correttamente un quartiere/zona di una citta'?
>

Cosa intendi con "aveva inglobato la città intera"?
Se intendi che in tutta la città i risultati delle ricerche dicevano che il
posto fosse in quel neighborhood, il problema non era il nodo in se ma il
fatto che non avesse confini.
Anche la pagina wiki di place=neighborhood [1] avverte del problema: "When
tagged as node, all the sorrounding addresses refer to this node and the
corresponding address is often wrong, expecially near borders. *Fix*: using
area/relation to define the boundary".
In questo caso la soluzione NON è eliminare il nodo ma è mappare i confini
del neighborhood.

Per mappare i confini prima di tutto devi creare i singoli segmenti di
confine come way e taggarli con boundary=administrative+admin_level=10 .[2]
Quindi devi creare una relazione  taggata
type=boundary+boundary=administrative+admin_level=10 .[3]
Infine devi aggiungere come membri della relazione tutti i segmenti con
ruolo "outer" e il place=neighborhood con ruolo "admin_centre".
Lo stesso discorso vale se invece di un place=neighborhood hai un
place=suburb/quarter/...

Se non conosci i confini esatti invece sei "in braghe di tela" perchè non
c'è una soluzione (che io sappia).

[1] https://wiki.openstreetmap.org/wiki/Tag:place%3Dneighbourhood#Issues
[2]
https://wiki.openstreetmap.org/wiki/Tag:boundary=administrative#10_admin_level_values_for_specific_countries

[3] https://wiki.openstreetmap.org/wiki/Relation:boundary


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

[OSM-talk-fr] Re : Re: repère géodésique détruit

2018-10-22 Per discussione Vincent de Château-Thierry

Bonjour,



Voir aussi 
https://wiki.openstreetmap.org/wiki/WikiProject_France/Rep%C3%A8res_G%C3%A9od%C3%A9siques#Supprim%C3%A9s



vincent

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

2018-10-22 Per discussione Florian Lohoff

On Mon, Oct 22, 2018 at 03:28:59PM +0200, "Christian Müller" wrote:
> M.E. ist deine Darstellung übertrieben und du unterschlägst,
> dass OSM ein Community-Projekt ist und erst nachrangig nackte
> Wissenschaft.

Ich habe mich auf dein "Wer misst misst Mist" bezogen.

> Außerdem:  Egal wie genau deine Messinstrumente sind, du kannst
> nie mit Sicherheit sagen, dass es keine genaueren geben kann, was
> deine Aussage(n) fatalistisch macht:  Nur weil ich nicht sicher
> sein kann, ob mein Messinstrument perfekt ist, soll ich nicht
> messen dürfen!?  Damit erstickst du jede Wissenschaft in den
> Kinderschuhen.  Bei der Lichtmikroskopie hat man auch gute Er-
> gebnisse erzielt, bevor ihre Anwendung unterhalb des Abbe-Limits
> ermöglicht wurde.  Und es ist auch nicht so, dass letztere die
> vorher verfügbaren Messinstrumente obsoletiert.

Doch kannst du - Und wenn du aber absichtlich Genauigkeit
wegwirfst und zwar in mehreren Größenordnungen dann ist das
absichtliche Fehlergenerierung. 

> Wenn ein grobes Luftbild vorliegt, handelt es sich doch längst
> nicht um reine Raterei, sondern um Schätzung in Kombination mit
> Erfahrungswerten, fehlerbehaftet gewiss, aber nicht unwissen-
> schaftlich.  Wer sagt, das Wissenschaft stets fehlerfrei ist?
> Wenn Daten mit Unsicherheit abgeleitet werden, geben Mapper bei
> großer eigener Unsicherheit ja oft mit FIXME=was auch an, dass
> die Genauigkeit der Erfassung in den mit Tag benannten Bereichen
> klein ist.

Genau - Und dann ist verkleben immer noch falsch. Weil du weisst
das eine Straße eine Breite hat und du weisst das die mind. 5m Breit
ist. Wenn deine Straße also nur 1 Pixel breit ist weisst
du das der Landuse faktisch trotzdem 4m daneben erst losgeht.
Also verkleb doch nicht sondern leg mit Editores Hilfe den
Landuse daneben. Verkleben ist definitiv falsch und hat
als Fehler mindest 1/2 Straßenbreite + Lagefehler. Das danebenlegen
hat Straßenbreitenschätzfehler + Lagefehler. Das sollte
um mehrere Größenordnungen kleiner als ersterer Weg sein.

Verkleben ist das vorsätzliche hinzufügen von Fehlern zum zwecke
der Generalisierung.

> Ja, Paper werden zurückgezogen.  Ja, FIXME=* Daten dürfen ver-
> bessert werden.  Ja, "we map what's on the ground" _to best
> possible effort_.  Der eine hat dabei mehr Ressourcen, der
> nächste trägt mit weniger Mitteln bei.  So ist das auch in
> der Wissenschaft, deren Betreiben jedem/jeder frei gestellt
> ist.

Das einzeichnen von Landuses/Flächen ohne zuhilfenahme von Nodes
der Straße geht genauso schnell. Das rumschieben von nodes um
es zu verbessern geht auch schnell. Das ablösen von Nodes
um es zu verbessern ist was für jemanden der auch Vater und Mutter
erschlagen hat.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

M.E. ist deine Darstellung übertrieben und du unterschlägst,
dass OSM ein Community-Projekt ist und erst nachrangig nackte
Wissenschaft.

Außerdem:  Egal wie genau deine Messinstrumente sind, du kannst
nie mit Sicherheit sagen, dass es keine genaueren geben kann, was
deine Aussage(n) fatalistisch macht:  Nur weil ich nicht sicher
sein kann, ob mein Messinstrument perfekt ist, soll ich nicht
messen dürfen!?  Damit erstickst du jede Wissenschaft in den
Kinderschuhen.  Bei der Lichtmikroskopie hat man auch gute Er-
gebnisse erzielt, bevor ihre Anwendung unterhalb des Abbe-Limits
ermöglicht wurde.  Und es ist auch nicht so, dass letztere die
vorher verfügbaren Messinstrumente obsoletiert.

Wenn ein grobes Luftbild vorliegt, handelt es sich doch längst
nicht um reine Raterei, sondern um Schätzung in Kombination mit
Erfahrungswerten, fehlerbehaftet gewiss, aber nicht unwissen-
schaftlich.  Wer sagt, das Wissenschaft stets fehlerfrei ist?
Wenn Daten mit Unsicherheit abgeleitet werden, geben Mapper bei
großer eigener Unsicherheit ja oft mit FIXME=was auch an, dass
die Genauigkeit der Erfassung in den mit Tag benannten Bereichen
klein ist.

Ja, Paper werden zurückgezogen.  Ja, FIXME=* Daten dürfen ver-
bessert werden.  Ja, "we map what's on the ground" _to best
possible effort_.  Der eine hat dabei mehr Ressourcen, der
nächste trägt mit weniger Mitteln bei.  So ist das auch in
der Wissenschaft, deren Betreiben jedem/jeder frei gestellt
ist.

Gruß

> On Mon, Oct 22, 2018 at 01:57:03PM +0200, Florian Lohoff wrote:
> 
> Aber dinge eintragen von denen ich nicht einmal gesichert sagen kann 
> ob sie wirklich existieren ist halt unwissenschaftlich. Das hat
> mit messen nichts zu tun sondern mit Raten und das sind dann die
> Paper die irgendwann zurückgezogen werden.
> 
> > Du hast recht, das schlechte Luftbilder sehr viel Raum für Fehl-
> > interpretationen liefern, aber das war in OSM noch nie Kriterium
> > dafür, gar nichts einzutragen.  Die Arbeitsweise ist eine, die
> 
> Doch - Das ist ein Kriterium. Das steht in den Best Mapping Practices.
> "We map whats on the ground" - Nicht mehr oder weniger. Etwas
> reinraten und als Entschuldigung schlechte Luftbilder angeben ist
> halt quatsch. Wie es Linus Torvalds mal sinngemäß gesagt hat: Ich kann
> pi in einer Sekunde bis zur 100sten Stelle berechnen solange
> das nicht richtig sein muss. 
> 
> Flo

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

2018-10-22 Per discussione Florian Lohoff

On Mon, Oct 22, 2018 at 12:25:39PM +0200, sepp1...@posteo.de wrote:
> Wäre es das? Das Aufteilen der Flächen in handhabbare Größen sind doch rein
> administrative und willkürliche Maßnahmen die so in der Realität nicht
> vorhanden sind, dito Grenzen (egal welcher Art), auch wenn es in den meisten
> Fällen eine Art Grenzbebauung oder -bepflanzung gibt.

Bei Wäldern weiss ich nicht. Bei Ackerflächen teile ich gerne an
Bewuchsgrenzen da das typischerweise auch grenzen der Pacht, der
Gemarkung, der Parzelle sind. Und was heute noch Wiese ist muss ja kein
Dauergrünland sein. Dann kann ich durch ändern des landuse tags etwas
von Wiese zu Acker oder umgekehrt machen.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away

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

Re: [OSM-talk-fr] repère géodésique détruit

2018-10-22 Per discussione marc marc

Le 22. 10. 18 à 14:43, François Lacombe a écrit :
> Sur le même sujet, j'ai supprimé environ 150 pylônes RTE qui ont été 
> démontés entre Charleville Mezieres et Reims hier soir.
> Certains avaient des points géodésiques que j'ai laissé.
> https://www.openstreetmap.org/node/669984935
> Dois-je mettre un end_date ?

si c'était un autre chose, je l'effacerais... mais un repère géodésique
je me dis que tu monde va le chercher parfois, croyant que c'est 
involontaire, alors c'est mieux de renseigner ce qui lui est arrivé.

end_date= (pour si quelqu'un veut retrouver quand il a été détruit)

was:man_made=survey_point (ou n'importe quel autre prefix de cycle
de vie plus précis si tu prèfères) sans quoi ceux qui se base
sur le tag principal sont induit en erreur, pensant qu'il y a un repère

> ou être déplacés consécutivement

je n'ai pas saisis ce que tu voulais dire.
si le repère était sur le poteau supprimé,
comment le repère pourrait avoir été simplement déplacé ?
j'ignore si l'ign compte remettre un nouveau repère proche
lorsqu'un repère est détruit, mais si c'est le cas,
j'espère qu'il n'aura pas la même ref, que ce serra un nouveau
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Spartanburg County SC road centerlines import

2018-10-22 Per discussione Mike N


On 10/22/2018 8:46 AM, Richard Fairhurst wrote:

Could I suggest that you act cautiously wrt the tiger:reviewed tag in these
two cases?

If it's an "unknown highway type" it should probably remain as
tiger:reviewed=no. Likewise, if the surface isn't clear, then either
tiger:reviewed should continue to be =no, or there should be some other
tagging to indicate this (surface=unknown, or surface:reviewed=no, or
something).


  As one who grew up in a rural area, a country road lined with 4 
houses in a mile would feel "residential" and I would tend to set it as 
residential in OSM.   That describes most of the rural parts of this 
county also, except for roads that don't happen to have a house.


  We could add Bing streetside to the workflow to confirm the surface 
type in most of the edge cases.


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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

Am Mo., 22. Okt. 2018 um 14:55 Uhr schrieb "Christian Müller" :

> Gemeint ist:  Wenn sich jemand 150,78 km/h fortbewegt, dann ist
> eine Messung, die das mit Fehler +/- 10 km/h misst, ein Faktum,
> genau so, wie jene, welche die Bewegung mit Fehler +/- 1 km/h
> Toleranz misst.




ja, aber was auch bereits erwähnt wurde: wenn die Messung nur mit +/ - 100
km/h erfolgte, dann kann man mit dem Wert für viele Zwecke nichts anfangen,
z.B. könnte man darauf beruhend keinen Strafzettel vergeben. Genausowenig
kann man Gebäudeformen oder Gartenzäune mit landsat mappen ;-)

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

Mit Fehler behaftete bzw. ungenaue Fakten sind nunmal auch Fakten,

Gemeint ist:  Wenn sich jemand 150,78 km/h fortbewegt, dann ist
eine Messung, die das mit Fehler +/- 10 km/h misst, ein Faktum,
genau so, wie jene, welche die Bewegung mit Fehler +/- 1 km/h
Toleranz misst.

Dazu analog ist m.E. die Problematik ungenau eingetragener Grenzen
im Datenbestand der OSM-DB.  Sie hängt wie genanntes Beispiel von
den verwendeten Messinstrumenten bzw. -methoden ab.

Gruß

> On Mon, Oct 22, 2018 at 08:27, "Florian Lohoff" wrote:
> 
> Ziehen des Landuses bis zum verkleben an die Straße ist IMMER falsch -
> 
> Flo

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

2018-10-22 Per discussione Florian Lohoff

Hola,

On Mon, Oct 22, 2018 at 01:57:03PM +0200, "Christian Müller" wrote:
> Mit Fehler behaftete bzw. ungenaue Fakten sind nunmal auch Fakten,
> da kannst du dich noch so sehr bemühen, deine Definition derer als
> die alleinige Wahrheit anzupreisen ;-).  Es gilt:
>   "Wer misst, misst Mist."
> und diese Ingenieursweisheit verschwindet auch im cm-Bereich nicht.

Aber dinge eintragen von denen ich nicht einmal gesichert sagen kann 
ob sie wirklich existieren ist halt unwissenschaftlich. Das hat
mit messen nichts zu tun sondern mit Raten und das sind dann die
Paper die irgendwann zurückgezogen werden.

> Du hast recht, das schlechte Luftbilder sehr viel Raum für Fehl-
> interpretationen liefern, aber das war in OSM noch nie Kriterium
> dafür, gar nichts einzutragen.  Die Arbeitsweise ist eine, die

Doch - Das ist ein Kriterium. Das steht in den Best Mapping Practices.
"We map whats on the ground" - Nicht mehr oder weniger. Etwas
reinraten und als Entschuldigung schlechte Luftbilder angeben ist
halt quatsch. Wie es Linus Torvalds mal sinngemäß gesagt hat: Ich kann
pi in einer Sekunde bis zur 100sten Stelle berechnen solange
das nicht richtig sein muss. 

Wenn schlechte Luftbilder als Entschuldigung für kaputte Daten herhalten
dann male ich heute einfach noch so 2-3 Mio Gebäude bei OSM rein!??

Ernsthaft?

> inkrementell die Daten überarbeitet, je nach Kenntnisstand.  Das
> wird auch dann so sein, wenn die hoch aufgelösten Luftbilder dem
> Projekt ggf. nicht mehr zur Verfügung stehen.  Die Abweichung der
> Geometrien zur Realität würde dann wieder größer, aber etwas,
> das ungefähr die Realität wiedergibt, ist eben besser, als hoch-
> präzise, aber inaktuelle Daten:

Du kannst dann ja alle Gebäude von meinen 2-3 Mio die ich reinmale
Löschen die wirklich nicht existieren. Aber schön manuell kontrollieren
und jedes das du löscht frage ich nach wie du drauf kommst.

> Das kannst du auch überall dort sehen, wo gebaut wird.  I.d.R.
> erfolgt die Anpassung der Daten an eine präzisere Fassung erst,
> wenn die Objekte später auf Luftbildern zu sehen und dann ab-
> zeichenbar sind - die Erfassung findet aber oft weit vorher
> statt und zu diesem Zeitpunkt ist es für OSM und viele seiner
> Anwendungen oft egal, ob z.B. die Mittellinie einer neuen
> Straße exakt an der geographisch korrekten Position liegt.

Ja - Aber da sieht man eine Baugrube - Ein Erdgeschoss - Das kann
ich einzeichnen - Da weiss ich das was da ist. Die Geometrie ist
vielleicht ein bisschen zu groß oder zu klein.

Aber die Ackerfläche bis an die Straße zu ziehen obwohl im Luftbild
erkennbar noch was dazwischen ist ist halt das faken von Daten.
Und wenn deine Luftbilder so schlecht sind das du nichts siehst
solltest du besser nichts davon einzeichnen.

> Die Diskussion um das Verkleben des Landuses hatten wir schon
> und es ist sinnlos, die immer gleichen Argumente immer wieder
> vorzutragen.  Das Hauptproblem ist, dass "falsch" und "rich-
> tig" nur in einem Kontext benutzbar sind, in dem definitorisch
> zunächst einmal genau geklärt ist, was wie im Datenmodell abge-
> bildet wird.  Dieses Modell als Grundlage von OSM war und ist
> aber nicht (komplett) interpretationsfrei.  Ein Großteil der
> Diskussionen und Konsensfindungsbemühungen beschäftigt(e) sich
> ja gerade damit, dieses Modell zu entwickeln.

Das hat mit dem Modell nichts zu tun. Nodesharing zwischen Flächen und
Wegen führt zu Fehlern - Faktischen, Semantischen - You name it.

Um das mal an einem Beispiel zu machen:

https://silicon-verl.de/home/flo/tmp/nodesharing.jpg

Hier mal eine beliebige Kreuzung auf dem Lande. Es gibt
die Nodes 1,2,3,4 und die Ackerflächen A/B/C

Nach dem "Verklebeprinzip" wird nur der Node 1 benutzt. Denn die
Straßen treffen sich dort und die 3 Angrenzenden Ackerflächen benutzen
als Ecknode jeweils Node 1.

Fehler die mir sofort ins Auge springen.

- Die Ackerflächen teilen sich einen Node und Kanten obwohl sie nicht
  aneinander Grenzen 
- Er werden Bankette, Straßengraben und Alleebäume unterschlagen die
  nicht zur Ackerfläche gehören. 
- Die Knoten liegen jeweils zur Kreuzungsmitte verlagert 
- Die jeweiligen Ackerflächen (Angenommen Quadratisch a*b) werden
  bei nur 5m Lagefehler um 10*a + 10*b größer. 
- Durch das teilen von Kanten wird dargestellt das ein Wechsel von
  Fahrbahn auf den Acker jederzeit möglich ist - Dank Graben geht das
  aber nicht.
- Es ist durch Lagebetrachtung von Nodes nicht mehr möglich zu
  entscheiden ob ein Acker links oder rechts der Straße liegt.

Dazu kommen Nachbearbeitungsprobleme:
- Im Knoten 1 sind 3 Flächen und 2 Straßen verbunden. Sind sie das
  wirklich oder sieht das nur so aus? Mit den derzeitigen Editoren 
  ist nicht ersichtlich ob ALLE übereinanderliegenden Wege in einem
  Knoten verbunden sind. Es ist nur sichtbar das mehr als ein Weg
  verbunden ist.
  Hier habe ich schon viele Routingprobleme behoben weil mal
  irgendjemand zwar eine Straße da angeschlossen hat - Aber eben nicht
  an die Straße sondern die nur

Re: [Talk-cz] historic=tomb se nerenderuje na Mapniku

2018-10-22 Per discussione xkomc...@centrum.cz

Když si tu query vyklikám přes Wizzard, tak mi to najde: 
https://overpass-turbo.eu/s/CZO



BTW: to jsem ani netušil, že v Knínicích mají v kostele kryptu :-O


On 22.10.2018 13:49, majka wrote:



On Mon, 22 Oct 2018 at 12:49, Vladimír Slávik 
mailto:slavik.vladi...@seznam.cz>> wrote:


Proč se nenajde třeba toto tím druhým dotazem, i když prvním ano?
Něco tam není úplně dobře...
https://www.openstreetmap.org/way/501707796
V+

Podle mě to asi schovává ta relace budovy, a building:part - 
předpokládám že to pak hledá jen to "navrchu". Tady jsou smíchané 
vzájemně nesouvisející značky, což je vždy problematické.
Z jakého důvodu je mezi těmi dotazy rozdíl netuším, zkoušela jsem to 
přepsat do naprosto stejné podoby, jen s rozdílem bbox x nadefinované 
území. Ten druhý dotaz mi pokaždé vrací jen body.



___
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-us] Spartanburg County SC road centerlines import

2018-10-22 Per discussione Richard Fairhurst

Mike N. wrote:
> This is a proposed import of road centerlines for Spartanburg County 
> SC, based on county GIS data. This will include a systematic review of 
> all roads in the county and qualify to remove tiger:reviewed tags.

Looks good!

Browsing through the code and the wiki page, you have:

>else:
>if hwy != '':
>print ('Unknown highway type:  ', hwy)
>tags['highway'] = 'residential'

and

> Add surface type as paved if it appears paved in imagery.

Could I suggest that you act cautiously wrt the tiger:reviewed tag in these
two cases?

If it's an "unknown highway type" it should probably remain as
tiger:reviewed=no. Likewise, if the surface isn't clear, then either
tiger:reviewed should continue to be =no, or there should be some other
tagging to indicate this (surface=unknown, or surface:reviewed=no, or
something).

cheers
Richard

--
Sent from: http://gis.19327.n8.nabble.com/USA-f5284732.html

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

Re: [OSM-talk-fr] Ces collectivités qui misent sur Openstreetmap et la cartographie participative

2018-10-22 Per discussione Philippe Verdy

Le lun. 22 oct. 2018 à 12:03, François Lacombe 
a écrit :

> C'est une très bonne chose que les collectivités se saisissent de cet
> outil et nous mettent en lumière par ailleurs.
>
> En parlant de mettre en lumière, la 1ere phrase est un peu étonnante. Elle
> installe la confusion.
>

Je ne pense pas car justement cette phrase dit "Un certain nombre de
collectivités proposent" puis "Elles s’appuient, notamment, sur
OpenStreetMap ".

Les collectivités citées sont celles qui ont pris ce choix de "s'appuyer"
et non développer elles-mêmes et inciter les citoyens à contribuer à leur
propre plateforme ou celle d'un autre tiers, jugé pas assez fiable ou
réactif (on peut citer le cas du cadastre avec le manque de réactivité de
la DGFiP qui ne réponds pas à tous les besoins des communes, ou encore
d'autres acteurs publics comme l'IGN).

De fait elles incitent leurs résidents ou visiteurs à contribuer sur une
plateforme qui leur donne cette réactivité et des mises à jour plus
régulières (auxquelles ces mêmes collectivités maintenant contribuent
directement, tout en fournissant par ailleurs des données open data dont
elles sont elles-mêmes à l'initiative, à charge pour nous de les intégrer
dans OSM si elles n'ont pas les moyens ou la capacité de faire elles-mêmes
le travail de fusion ou si leur contribution directe dans OSM les
obligerait à mettre en place un "bot" faisant des imports directs qui nous
poseraient problème puisque leurs propres données ne sont pas suffisantes
même pour leurs propres besoins ou leur coûtent cher à mettre à jour)

Donc l'article met plutôt en avant les collectivités qui ont fait le choix
d'aller au delà du simple "open data" avec des données parcellaires, plus
suffisamment précises ou rapidement obsolètes, mais qui ont malgré tout
l'avantage d'une bonne distribution pour leur couverture territoriale (pas
forcément utile pour une planification précise du territoire sans devoir
faire des études locales de terrain détaillées et les payer, mais utiles et
suffisantes pour un certain nombre d'usages statistiques où la précision
n'est ni nécessaire, ni même voulue si cette précision se heurte aux
contraintes du secret statistique imposé par la loi).

Il reste que pour bon nombres de projets d'aménagements ou pour la gestion
directe de données concernant leurs administrés, les collectivités ne
peuvent pas tout publier et doivent développer leur SIG, elles ont donc
l'habitude (et la nécessité) de travailler avec plusieurs sources
cartographiques : les leurs (privées dans certains cas, open data pour le
reste), et celles de leurs partenaires (tout ce qu'elles ne peuvent pas
maintenir elles-mêmes, dont IGN, DGFiP, et OSM).

Ces collectivités ne peuvent pas proposer à leurs citoyens de contribuer
ailleurs que sur OSM (le seul autre partenaire possible qui réponde à une
part significative de leurs besoins) si leur propre SIG ne dispose pas de
la capacité technique et humaine de gérer tout ce monde, puisque du côté de
la DGFiP ou l'IGN ce système ne fonctionne pas (l'IGN propose bien une
plateforme "participative", mais a lui-même du mal à gérer la qualité et le
volume, ces contributions ne sont donc pas prises en compte avec une
réactivité suffisante pour obtenir un retour utile aux collectivités qui en
ont des besoins plus rapides, l'IGN aussi ayant sévèrement limité le retour
d'informations et notamment la précision accessible ou le type de données
qu'elle accepte de gérer sur sa plateforme). La seule plateforme
participative qui ne restreint pas le type de données et est assez ouverte
pour répondre à tous types de besoin des collectivités c'est OSM, jusqu'à
preuve du contraire (ne parlons pas de Google qui lui se réserve une bonne
partie des données collectées et impose un filtrage excessif et des
conditions d'accès prohibitives même pour avoir une partie restreinte des
données collectées; Apple va faire la même chose puisqu'il annonce
maintenant qu'il va se passer de tous les fournisseurs tiers et donc
développer des données propriétaires sur la base de sa propre collecte, ou
ne garder qu'une plateforme de participation fermée où il agira en tant que
filtre pour tout et décider de publier ou pas. Ce qui est un problème aussi
pour les collectivités qui doivent pouvoir compter sur un accès permanent
et stable aux données et non dégradé au gré des seules décisions de Google
ou Apple pour l'usage de leur API qui peut leur fournir tout autre chose
que ce qu'elles ont demandé et obtenu une première fois mais plus ensuite).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

Am Mo., 22. Okt. 2018 um 13:06 Uhr schrieb Markus :

> Kling irgendwie logisch - aber wann grenzen sie "klar" aneinander?
>


wenn die Grenze des einen auch die Grenze des anderen ist. Die Grenze von
Wasser wäre z.B. nass, klares Beispiel wäre z.B. eine Spundwand (Vertikale,
feste, gebaute Uferbefestigung), die begrenzt die Wasserfläche, zwischen
ihr und dem Wasser noch eine Spalt freizulassen wäre "falsch".



> Das sind m.E. Topologiefehler,
>
> Ja. Denn gemeint ist ja, dass die Flächen zwar zusammengehören, aber
> zwecks besserer Bearbeitbarkeit trotzdem getrennt gemalt werden.
>
> Nein. Denn in Wirklichkeit ist das was wir als eindeutig getrennt
> attributieren, nichts Abgegrenztes, sondern fliessende Übergänge.
> Der Fehler liegt m.E. in der abgegrenzten und unsauberen Attributierung.
>
>

bei fließenden Übergängen ist die Sache unklar, auch wie man es am besten
mappen soll, ich würde mich in der Diskussion hier zunächst auf die klaren
Fälle beschränken, wo die Grenzen klar erkennbar sind, weil es auch dort
unterschiedliche Meinungen gibt, wie man es abbilden will, aber es sollte
dort zumindest klar sein, was es ist, das man abbilden will (und das
Datenmodell erlaubt es von sich aus, klare Grenzen klar zu zeichnen).


> Friedhof der ohne Straße dazwischen an ein Wohngrundstück angrenzt
> > (Grenzmauer zwischen den beiden, typischerweise)
>
> Jeder weiss, was ein "Friedhof" ist.
> Aber was ist das datentechnisch genau?
> - alles innerhalb der Gemarkungsgrenze?
>


falls das "Parzellengrenze" heissen sollte, nein (s.u.)



> - alles innerhalb der Aussenkante der Friedhofsmauer?
>


das ist vermutlich kulturell unterschiedlich, bei christlichen Friedhöfen
gibt es normalerweise (ja, gibt Ausnahmen), eine Mauer und das wäre für
mich die klare Grenze. Wenn ein Friedhof noch einen Parkplatz davor hat
(grundstückstechnisch), würde ich den eher nicht zum Friedhof schlagen
sondern für sich mappen. Die Mauer müsste schon sehr dick sein, dass Innen-
und Aussengrenze verschiedene Objekte wären.
Z.B. gibt es hier einen Friedhof an der Stadtmauer, das ist bisher immer
noch die Mauer als nur eine Linie gemappt (könnte man aber zugegebenermaßen
bei Gelegenheit mal nachholen): https://www.openstreetmap.org/way/24575663



> - was ist, wenn die Friedhofsmauer (teilweise) gleichzeitig die
>   Stadtmauer ist? was gehört dann zu "residental" bzw. "graveyard"?
>


alles bis Innenkante Stadtmauer würde ich sagen, ausser in der Mauer ist
auch noch Begräbnisstätte.



> - alles innerhalb der Innengrenze der Friedhofsmauer?
>


s.o. Außenkante




> - wann liegt der Friedhof "im Wald"?
>   wann liegt der Wald "im Friedhof"?
>   wann sind es gleichrangige Objekte?
>


ist z.B. eine Frage der Größen, jedenfalls kann das mit unseren Daten jeder
für sich entscheiden.


 - alles innerhalb das für Gräber vorgesehen ist?
>   (also nicht der Wald, nicht die Gebäude, nicht der Teich)
>
- nur die für Gräber vorgesehene Fläche (ohne Zufahrtswege)?
> - nur die für Gräber vorgesehene Fläche (ohne alle Wege)?
> - nur die für Gräber aktuell genutzte Fläche?
>


nein




>
> > 2 Gebäude die angebaut sind
>
> Jeder weiss, was ein "Gebäude" ist.
> Aber wann sind es "zwei"?
> - nur wenn sie keinerlei Verbindung haben?
> - was ist mit "angebaut"?
>   (Stall, Garage, Werkstatt, Lagerhalle, ...)
> - getrennte Fundamente und verbindende Pergola, Balkon, Dach?
> - gemeinsames Fundament/Keller, aber getrennte Gebäude?
> - gestapelt, z.B. Terrassenhaus
> - aneinandergebaute Stadthäuser mit gemeinsamer Aussenwand?
> - aneinandergebaute Häuser, wo eines die Aussenwand des anderen benutzt?
> - aneinandergebaute Häuser mit Brandschutzmauer?
>


gemeint war, dass es 2 Gebäude gibt, deren jeweilige Aussenwände sich
berühren, bzw. scheinbar berühren (1 Zentimeter Luft dazwischen oder so
gilt auch noch).
Dazu sagt man auch "angebaut". Üblicherweise müssen neuere Gebäude für sich
stehen, ohne sich irgendwo anzulehnen oder aufzustützen, aber es gibt in
der Tat noch solche Situationen aus historischen Gründen (sehr alte
Gebäude), wo 2 Gebäude nur eine gemeinsame Trennwand haben, oder auch
Verschachtelungen unterschiedlicher Besitze und Gebäude nur gemeinsam
stehen können. Das kann man sich jeweils aussuchen, ob man building oder
building:part verwendet, Hauptsache, man macht es ;-) Jedenfalls wären
diese Fälle bei dem vorgeschlagenen Modell nicht unterscheidbar von
unabhängigen Gebäuden, die sich berühren, und das macht auch nichts (wir
werden sowieso kaum in die Lage kommen, in solchen historischen
Innenstädten die Details zu kartieren/vermessen, sind ja meist
Privathäuser).



>
> > Gebäude die einen Platz begrenzen (Bezug ist also Platz und Gebäude)
> etc.).
> > Für diese Verbindung werden die Flächen an ihrer realen Grenze
> gezeichnet,
> > die "Berührungspunkte" jedoch gemeinsam mit den Nachbarn genutzt.
>
> Ich weiss nicht, ob das datentechnisch korrekt ausgedrückt ist:
> Für mich gehören Gebäude und Platz zu unterschiedlichen Objekt-Klassen.
>

Re: [OSM-talk-fr] repère géodésique détruit

Hello,

Sur le même sujet, j'ai supprimé environ 150 pylônes RTE qui ont été
démontés entre Charleville Mezieres et Reims hier soir.
Certains avaient des points géodésiques que j'ai laissé.
https://www.openstreetmap.org/node/669984935

Mais ces points ont du disparaître, ou être déplacés consécutivement aux
travaux sur place.
Dois-je mettre un end_date ?

François

Le dim. 21 oct. 2018 à 21:54, marc marc  a
écrit :

> Le 21. 10. 18 à 21:49, Alain VASSAULT a écrit :
> > tu as la ref du point geodesique ou ces coordonnées?
>
> il y les a 2, sur les 2 objets
> https://www.openstreetmap.org/node/67945
> https://www.openstreetmap.org/node/67946
>
> > jai l'appli "beta" librement dispo sur le google store
> > pour consulter et report sur les fiches geodesique.
>
> Je suis curieux de voir ce que cela va donner, merci.
>
> > Le 21 octobre 2018 21:45:43 GMT+02:00, David Crochet
> > a écrit :
> >
> > J'ai envoyé un message à l'adresse ad'hoc pour signaler la
> disparition
> > de la croix, avec photo d'un média audiovisuel  à l'appui :
>
> Merci, voyons voir leur réaction. au moins "osm" aura transmis :)
>
>  Message transféré 
> Sujet : repère géodésique détruit
> Date : Sun, 21 Oct 2018 20:29:10 +0200
> De : Marc M. 
> Pour : talk-fr 
>
> Bonjour,
>
> Un constructeur signale le démontage d'un clocher d'église qui
> hébergeait 2 repères géodésiques.
> https://www.openstreetmap.org/note/1563371
> https://www.openstreetmap.org/node/67945
> https://www.openstreetmap.org/node/67946
> au niveau osm, c'est facile
> was: devant le man_made=survey_point
> un end_date
> une maj de la description
>
> mais je demandais :
> - il y a a-t-il un outil QA qui va crier pour sa disparition ?
> Si oui quel schéma supporte-t-il ?
> - quelqu'un est en contact avec l'ign pour leur remonter l'info
> s'ils ne l'ont pas ?
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] [Imports-us] Spartanburg County SC road centerlines import

2018-10-22 Per discussione Mike N


Thank you for your comments.  Answers inline.

On 10/22/2018 5:00 AM, Rory McCann wrote:

On 22/10/2018 05:20, Mike N wrote:
This is a proposed import of road centerlines for Spartanburg County 
SC, based on county GIS data.   This will include a systematic review 
of all roads in the county and qualify to remove tiger:reviewed tags.


https://wiki.openstreetmap.org/wiki/Spartanburg_county_road_center_line_import 



A roads import! 

There's a few lanes that are weird. lanes=7 for a 6 lane road. It's 
weird that some roads have lanes on some parts, not all (e.g. "Hollywood 
Street"). Maybe try to make it consistant? JOSM validator has found a 
handful of topology errors. There's ~100 examples of roads that aren't 
connected properly (nodes on top of each other, but not connected).


You seem to be defaulting to "highway=residential" a lot (e.g. if you 
dohn;t know another, or turning 'Gravel' into 'highway=residential 
surface=gravel'). I don't know a lot about tagging in the USA, but isn't 
there (wasn't there) some problem with the TIGER data using residential 
too much?


  The 'lanes' and highway type were experimental to see what useful 
information could be mined from the source data.   I agree that they are 
all but useless for OSM's purpose.  95% of the work will be checking for 
geometric alignment and name from the background image layer in the 
editor.   For example there have been many projects where sharp 
intersections have been realigned for safety to create right angles. 
And streets have been renamed for E911 purposes.


   The one case where I see direct access to converted data is a new 
residential subdivision - where a new group of roads would be copied 
from the reference data and connected to existing data.   Those would 
nearly all be residential.  So I didn't take the time to go back and 
remove lane attributes from the raw data.


   Defaulting to residential was not totally wrong for this county in 
the same way it was wrong out west.  The most likely mismatch would be a 
new unclassified road into an industrial area - but those will likely be 
single roads, and thus be as easy to hand trace and assign the correct 
classification as to copy from the reference layer.


Can you link to your discussion with the local community, how/where did 
that happen?


  This was mostly verbal discussion with another community member, as 
well as one of the meetups at 
https://www.meetup.com/Open-Street-Map-upstate/ , and using some of the 
ideas presented by Clifford Snow in his "Discover Rural America" 
presentation at https://www.youtube.com/watch?v=EoX2Q2aJXQE=1211s .



The link the tasking manager project doesn't work.


   Corrected.

I'm a little unclear about one big question: What are you doing with the 
existing data in OSM? Existing OSM data seems to have nearly identical 
locations to this new data. You're just going to update existing OSM 
data? Do you know how much existing OSM data needs to be updated?


  All existing data will be reviewed.   Most of it will add the surface 
attribute and lanes if visible from imagery and remove the 
tiger:reviewed attribute.   So nearly everything will be modified.


   Stepping back to the big picture - although many hours have been 
spent improving the road network in that county, OSM is the last source 
I would use when planning a trip to an unfamiliar part of the county. 
There have been other US projects in which a group would go into a "fast 
growing region" and review all roads, adding surface and lane attributes 
to improve navigation.   The end goal of this project is similar.   When 
combined with some additional planned work such as address points, OSM 
will be suitable as the primary reference source when planning a trip 
through that county.


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

Re: [OSM-talk-ie] OpenStreetMap Ireland CLG launch yesterday

2018-10-22 Per discussione Colm Moore

Ciarán & board,

Well done on setting things up!

One thing we might do is to promote OSM, based on those that are using the data 
already:

* NTA: www.rtpi.ie
* Dublin Fire Bridge - maps on Twitter.
* Dublin City Council self service portal - 
http://www.dublincity.ie/main-menu-your-council/isupport
* Met Éireann - https://www.met.ie/

I'm sure there are more.

Colm


  
---
Never doubt that a small group of thoughtful, committed citizens can change the 
world. Indeed, it is the only thing that ever has. Margaret Mead



From: talk-ie-requ...@openstreetmap.org 
Sent: 22 October 2018 13:01
To: talk-ie@openstreetmap.org
Subject: Talk-ie Digest, Vol 113, Issue 10


Send Talk-ie mailing list submissions to
talk-ie@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
 
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openstreetmap.org%2Flistinfo%2Ftalk-iedata=02%7C01%7C%7C30ba719ee5de45c1532608d63817087f%7C84df9e7fe9f640afb435%7C1%7C0%7C636758068903216965sdata=aYM1N3lSYoxr4dDzI38BjfnOQVDuIX3JjqjP2EW7tEo%3Dreserved=0
or, via email, send a message with subject or body 'help' to
talk-ie-requ...@openstreetmap.org

You can reach the person managing the list at
talk-ie-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Talk-ie digest..."


Today's Topics:

   1. Re: OpenStreetMap Ireland CLG launch yesterday (Ciarán Staunton)


--

Message: 1
Date: Sun, 21 Oct 2018 13:08:58 +0100
From: Ciarán Staunton 
To: Discussion of OpenStreetMap in Ireland 
Subject: Re: [OSM-talk-ie] OpenStreetMap Ireland CLG launch yesterday
Message-ID:

Content-Type: text/plain; charset="UTF-8"

Greetings All
On behalf of the board I want to thank you for attending the launch and the
open mic event yesterday.

For the benefit of those that missed it we saw a fantastic look back at the
history of the community from mackerski. dónál went through the legalities
of the company set up, how we got to where we are now and that we will be
formally applying for chapter status with osmf. I myself (debigc) let
everyone know what to expect in term of activity for the next year, as we
bring the participation, connection, visibility and exchange to the next
level.

The open mics were all really interesting too, to summarise them we would
have to point to the diversity of platforms, motivations, focus, interest
that is out there in the broader community. The wealth of the asset that is
openstreetmap is the wealth of the knowledge you are all putting into it.
As all the speakers at the start said in one way or another pulling
together and being more coherent as a community is where we are navigating
to right now.

Keep up the great work everyone!


--

Subject: Digest Footer

___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.openstreetmap.org%2Flistinfo%2Ftalk-iedata=02%7C01%7C%7C30ba719ee5de45c1532608d63817087f%7C84df9e7fe9f640afb435%7C1%7C0%7C636758068903216965sdata=aYM1N3lSYoxr4dDzI38BjfnOQVDuIX3JjqjP2EW7tEo%3Dreserved=0


--

End of Talk-ie Digest, Vol 113, Issue 10


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

Re: [OSM-talk] Fwd: DWG policy on Crimea

Can you summarize parts of this article (5k+ words, in "long read" section) 
that are relevant totagging of Russian and Ukrainian border in the Crimea?

22. Oct 2018 00:44 by oleksiy.muzal...@bluewin.ch 
:


> > Hi Martin,
>   
>   Before continuing this discussion further, I would advise to read  
> the amazing article "The demise of the nation state" by Rana  Dasgupta 
> available via this link:> 
> https://www.theguardian.com/news/2018/apr/05/demise-of-the-nation-state-rana-dasgupta
>  
> 
>   
>   The issue of national state boundaries is more profound and  
> ubiquitous than it may seem at first sight. This topic is  controversial 
> and complicated, and Rana Dasgupta's analyses  provides some good 
> starting-point insights.
>   
>   Best regards,
>   Oleksiy
>    
>   On 21.10.18 16:12, Martin Koppenhoefer wrote:
> > 
>> >>   >> Dear all,
>> >> >> we all know how sensible the topic of disputed 
>> boundaries  can be (they are not necessarily a big problem, many 
>> boundary  disputes like between Italy and France about the summit of 
>>  Mont Blanc / Monte Bianco, have little bearing on the actual
>>   life of people).>> 
>> >> >> Therefore we can all be satisfied there is clear 
>> guidance  from the board how to deal with this: the local situation  
>> determines how we map, and the OSMF is explicit here:  
>> “National borders are particularly sensitive. Currently, we  record 
>> one set that, in OpenStreetMap contributor opinion, is  most widely 
>> internationally recognised and best meets  realities on the ground, 
>> generally meaning physical control.”>> 
>> >> >> 
>> https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation. 
>> >>
>>  pdf >> 
>> >> >> When I recently looked at Crimea I noticed it is still 
>> part  of the Ucraine in OSM: >> 
>> https://www.openstreetmap.org/relation/60199 
>> >> 
>> >> >> As many might know, the current boundary situation for 
>>  Crimea was frozen 4 years ago “for a short time” by the DWG 
>>  and so I asked them about their current position 2 months ago,  and 
>> after I got no reply, tried to remind them 5 weeks ago,  but have 
>> not yet gotten any reply, so I am now opening this  thread here.>>   
>>   
>> >> >> IMHO, for consistency and credibility, we should 
>> either  recognize that Russia is actually controlling Crimea, or we  
>> should update the disputed borders information. As I believe 
>>  the general concept of ground truth for admin boundaries was a  
>> good idea, I would tend to the former.>> 
>> >> >> I also believe the actual situation has already been   
>>ignored for too long. When the thing is still dynamic or/and  
>> we’re in the middle of a conflict it can be wise to step back  and 
>> see for some time how things are evolving, but 4 years are  a lot of 
>> time, something like one year would seem more  reasonable.>> 
>> >> >> What do you think?>> 
>> >> >> Cheers, Martin 
>>   
>>   >> sent from a phone>>   
>> Begin forwarded message:
>> 
>>   >>   
>>> >>> From:>>>  Martin Koppenhoefer <>>> dieterdre...@gmail.com 
>>> 
>>>   >>> Date:>>>  20. August 2018 at 10:42:33 CEST
>>>   >>> To:>>>  >>> d...@osmfoundation.org 
>>> 
>>>   >>> Subject:>>>  >>> DWG policy on Crimea
>>>   
>>> >>>   
>>   
>>> >>> 
>>>   >>>   >>> Dear members of the DWG,>>> 
>>>   
>>>   >>>   >>> as of this question in the help 
>>> forum:>>>   
>>>   >>>   >>> 
>>> https://help.openstreetmap.org/questions/65436/what-is-the-current-position-of-the-dataworkinggroup-on-crimea
>>>  
>>> >>     
>>>   >>>   >>> I kindly invite you to reconsider and 
>>> eventuallyupdate your position on the situation in 
>>> Crimea.>>>   
>>>   >>>   >>> As you have stated

Re: [OSM-talk] Fwd: DWG policy on Crimea

21. Oct 2018 23:19 by yuriastrak...@gmail.com :


> I think a country relation should describe how the specific country think of 
> its borders. So if two countries claim the same territory, those two 
> relations will overlap.




That is absurd and conflict with OSM rule to map what exists. 

 
> E.g. it would be illegal in some countries to generate political map not 
> according to that country's government.  




It is also against Chinese law to publish accurate maps of China. It is not a 
sufficient reason 


to forbid accurate mapping of China in OSM.





https://en.wikipedia.org/wiki/Restrictions_on_geographic_data_in_China 



 

> So when I generate a map for Russia, I have to show Crimea as part of Russia. 
>  For Ukraine - as part of Ukraine.  Same for China and India and ...




There are also other sources of data. For example to show proper terrain shape 
or to show

ratings of restaurants and for many others use cases OSM is not sufficient.

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

Mit Fehler behaftete bzw. ungenaue Fakten sind nunmal auch Fakten,
da kannst du dich noch so sehr bemühen, deine Definition derer als
die alleinige Wahrheit anzupreisen ;-).  Es gilt:
  "Wer misst, misst Mist."
und diese Ingenieursweisheit verschwindet auch im cm-Bereich nicht.

Du hast recht, das schlechte Luftbilder sehr viel Raum für Fehl-
interpretationen liefern, aber das war in OSM noch nie Kriterium
dafür, gar nichts einzutragen.  Die Arbeitsweise ist eine, die
inkrementell die Daten überarbeitet, je nach Kenntnisstand.  Das
wird auch dann so sein, wenn die hoch aufgelösten Luftbilder dem
Projekt ggf. nicht mehr zur Verfügung stehen.  Die Abweichung der
Geometrien zur Realität würde dann wieder größer, aber etwas,
das ungefähr die Realität wiedergibt, ist eben besser, als hoch-
präzise, aber inaktuelle Daten:

Das kannst du auch überall dort sehen, wo gebaut wird.  I.d.R.
erfolgt die Anpassung der Daten an eine präzisere Fassung erst,
wenn die Objekte später auf Luftbildern zu sehen und dann ab-
zeichenbar sind - die Erfassung findet aber oft weit vorher
statt und zu diesem Zeitpunkt ist es für OSM und viele seiner
Anwendungen oft egal, ob z.B. die Mittellinie einer neuen
Straße exakt an der geographisch korrekten Position liegt.

Die Diskussion um das Verkleben des Landuses hatten wir schon
und es ist sinnlos, die immer gleichen Argumente immer wieder
vorzutragen.  Das Hauptproblem ist, dass "falsch" und "rich-
tig" nur in einem Kontext benutzbar sind, in dem definitorisch
zunächst einmal genau geklärt ist, was wie im Datenmodell abge-
bildet wird.  Dieses Modell als Grundlage von OSM war und ist
aber nicht (komplett) interpretationsfrei.  Ein Großteil der
Diskussionen und Konsensfindungsbemühungen beschäftigt(e) sich
ja gerade damit, dieses Modell zu entwickeln.

Und so kann eben überall dort, wo es keine mathematisch exakte
Beschreibung der Features, aber stattdessen einen Spielraum
für Interpretation gibt, je nach Verständnis und ggf. auch
Anwendungsfall "richtig" sein, was nach anderem Verständnis
eben falsch ist.

In Gebieten, wo auf Luftbildern im Pixelbereich gerade so zu er-
kennen ist, dass eine Straße links und rechts von Acker gesäumt
wird, reicht die Information (Acker | Straße | Acker) für viele
Anwendungszwecke nunmal aus, egal wie gut oder schlecht/ungenau
die Landuse-Grenze in der DB repräsentiert wird und auch egal
ob sie verklebt ist, oder nicht.

Woher kommt eigentlich der Zwang, dieses Problem "per Dekret"
von oben herab lösen zu müssen?  Nach meiner Beobachtung löst
sich das Verkleben in Regionen mit gut aufgelösten Luftbildern
mittelfristig von selbst - denn dort konvergieren die einge-
tragenen Landuse-Grenzen gegen das, was auf dem Luftbild zu
erkennen ist.  Wenn Alt-Daten nicht mehr oder sehr schlecht
zum Status-Quo eines guten, aktuellen Luftbildes passen, dann
wird bei der Überarbeitung dieser Daten häufig intuitiv "ent-
klebt".  Und auch in solchen Fällen, in denen weiterhin ver-
klebt wird, rückt die Flächengrenze (etwa als Neueintrag) an
eine Position mit kleinerem Fehler (sofern die Georeferen-
zierung mitspielt).

Ein höher aufgelöstes Luftbild bringt aber i.d.R. andere
Probleme mit sich, denn die Auflösung bedingt auch eine ver-
änderte Wahrnehmung der Objekte mit sich.  Die Frage etwa
danach, was genau ein "Wohngebiet" ist und über welche Flä-
che es sich erstreckt (und auch ob Straßenflächen nun dazu
gehören oder nicht) wird bei einem niedrig aufgelösten Luft-
bild anders beantwortet, als wenn eines mit hoher Auflösung
betrachtet wird.

Überspitzt formuliert:  Falls ein Luftbild einzelne Grashalme
auflöst, stellt sich erneut die Frage, ob die ggf. von ihnen
geformte Wiese, die auf einer anderen Zoomstufe klar zusammen-
hängend erkennbar ist, nicht doch an der einen oder anderen
Stelle eine Diskontinuität aufweist und deshalb "richtig"-
erweise in separat gemappten Flächen erfasst werden sollte.

(Wenn bei Google automatisiert mit Laser-Ranging vermessen
wird, stellt sich die Frage nicht, denn die identifizieren
die Objekte (zunächst) nicht, sondern kümmern sich nur um
die Wiedergabe eine (gigantisch großen) Punktmenge, die so
ge-shaded wird, dass die Farbgebung der entspricht, die man
auch vor Ort wahrnehmen würde.  Was welches Objekt ist, liegt
dann im Auge des Betrachters.  Das bezieht sich nicht auf
die "normale" Google Maps Darstellung, sondern auf die Web-
GL Darstellung bei hoher Zoomstufe in fotorealistischem 3D.)

Das eine Objektgrenze von Baumkronen überlappt wird, bzw. durch
Schattenwurf verzerrt und suggestiv wiedergegeben wird, wenn
mit Luftbildern gearbeitet wird, mag sein.  Es ist in diesen
Fällen eine Frage der Übung bzw. der Erfahrung, wie gut diese
Bilder beim Ableiten von geographischen Features ausgewertet
werden (können).  Phrase dazu:
  "Es ist noch kein Meister vom Himmel gefallen."

Gruß

> On Mon, Oct 22, 2018 at 08:27, "Florian Lohoff" wrote:
> 
> Aeh ja - nein - Wenn dein Luftbild so schlecht ist das du das nicht
> erkennen kannst

Re: [Talk-cz] historic=tomb se nerenderuje na Mapniku

2018-10-22 Per discussione majka

On Mon, 22 Oct 2018 at 12:49, Vladimír Slávik 
wrote:

> Proč se nenajde třeba toto tím druhým dotazem, i když prvním ano? Něco tam
> není úplně dobře...
> https://www.openstreetmap.org/way/501707796
> V+
>
Podle mě to asi schovává ta relace budovy, a building:part - předpokládám
že to pak hledá jen to "navrchu". Tady jsou smíchané vzájemně nesouvisející
značky, což je vždy problematické.
Z jakého důvodu je mezi těmi dotazy rozdíl netuším, zkoušela jsem to
přepsat do naprosto stejné podoby, jen s rozdílem bbox x nadefinované
území. Ten druhý dotaz mi pokaždé vrací jen body.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

2018-10-22 Per discussione Markus

Hallo Martin, Frederik und alle,

> danke für die Initiative Frederik. 

:-)

> auf den Kontext ankommt.
Ja, kontextbezogene konkrete Musterbeispiele wären sehr hilfreich!

Vermutlich können wir nur anhand konkreter und detaillierter Beispiele
unsere Begriffsverwirrung und die dadurch entstehenden Missverständnisse
(und vermutlich oft unnötigen Auseinandersetzungen) auflösen.

Beispiel:

> 1. Wenn 2 Flächen klar aneinandergrenzen, dann sollten sie m.E. gemeinsame
> Nodes haben, also verbunden sein. 

Kling irgendwie logisch - aber wann grenzen sie "klar" aneinander?
Immer dann,wenn der Renderer nichts mehr "Weisses" dazwischenmalt?

> Was man in Deutschland oft sieht, sind Nodes die sehr
> nahe aneinanderstehen (<1m) aber getrennte Nodes sind. 

Ja, und weil DE-Mapper so viel mappen,wirkt das als "Vorbild"...

> Das sind m.E. Topologiefehler,

Ja. Denn gemeint ist ja, dass die Flächen zwar zusammengehören, aber
zwecks besserer Bearbeitbarkeit trotzdem getrennt gemalt werden.

Nein. Denn in Wirklichkeit ist das was wir als eindeutig getrennt
attributieren, nichts Abgegrenztes, sondern fliessende Übergänge.
Der Fehler liegt m.E. in der abgegrenzten und unsauberen Attributierung.

> weil man aus den Daten m.E. explizit erkennen können soll,
> ob 2 Flächen sich nur zufällig nahe kommen oder eine gemeinsame Grenze
> haben 

Dazu müssten wir:
a) eine Darstellungsform für fliessende/diffuse Objekte erfinden
b) genau(er) definieren und unterscheiden
   (und an konkreten Beispielen differenziert beschreiben)

> Friedhof der ohne Straße dazwischen an ein Wohngrundstück angrenzt 
> (Grenzmauer zwischen den beiden, typischerweise)

Jeder weiss, was ein "Friedhof" ist.
Aber was ist das datentechnisch genau?
- alles innerhalb der Gemarkungsgrenze?
- alles innerhalb der Aussenkante der Friedhofsmauer?
- was ist, wenn die Friedhofsmauer (teilweise) gleichzeitig die
  Stadtmauer ist? was gehört dann zu "residental" bzw. "graveyard"?
- alles innerhalb der Innengrenze der Friedhofsmauer?
- alles innerhalb das für Gräber vorgesehen ist?
  (also nicht der Wald, nicht die Gebäude, nicht der Teich)
- wann liegt der Friedhof "im Wald"?
  wann liegt der Wald "im Friedhof"?
  wann sind es gleichrangige Objekte?
- nur die für Gräber vorgesehene Fläche (ohne Zufahrtswege)?
- nur die für Gräber vorgesehene Fläche (ohne alle Wege)?
- nur die für Gräber aktuell genutzte Fläche?
- ...

> 2 Gebäude die angebaut sind

Jeder weiss, was ein "Gebäude" ist.
Aber wann sind es "zwei"?
- nur wenn sie keinerlei Verbindung haben?
- was ist mit "angebaut"?
  (Stall, Garage, Werkstatt, Lagerhalle, ...)
- getrennte Fundamente und verbindende Pergola, Balkon, Dach?
- gemeinsames Fundament/Keller, aber getrennte Gebäude?
- gestapelt, z.B. Terrassenhaus
- aneinandergebaute Stadthäuser mit gemeinsamer Aussenwand?
- aneinandergebaute Häuser, wo eines die Aussenwand des anderen benutzt?
- aneinandergebaute Häuser mit Brandschutzmauer?

Und je nach Situation wäre dann zu bestimmen, wann und warum man besser
gemeinsame Punkte benutzt, und wann besser getrennte.

> Gebäude die einen Platz begrenzen (Bezug ist also Platz und Gebäude) etc.).
> Für diese Verbindung werden die Flächen an ihrer realen Grenze gezeichnet,
> die "Berührungspunkte" jedoch gemeinsam mit den Nachbarn genutzt.

Ich weiss nicht, ob das datentechnisch korrekt ausgedrückt ist:
Für mich gehören Gebäude und Platz zu unterschiedlichen Objekt-Klassen.
(unterschiedliche Bauart, Nutzungsart, Funktion, ...)
Wenn ich eines der beiden Objekte verändere (Gebäude teilweise
anbauen/abreissen/umwidmen, Platz teilweise umfunktionieren: Park-,
Markt-, Spiel-, Fussball-, Wald, Industriegebiet, Schrebergarten),
dann wird irgendwie intuitiv klar, dass Platz und Haus nicht wirklich
"gemeinsam" sind.

> 1b. Flächen die an Linien grenzen. Hier würde ich es wie 1 sehen im Falle,
> dass die Linie die Fläche begrenzt (es also nichts zwischen der Linie und
> der Fläche gibt) und sie nicht zu breit ist (unter 50cm "Dicke"?) also die
> begrenzende Linie z.B. eine Mauer oder ein Zaun ist, und die Fläche für das
> Verbinden nicht merklich vergrößert werden muss.
> 
> 
> 2. Mitte der Straßen (highway) mit angrenzenden Flächen verbunden 

Ja, das ist vermutlich Konsens für "deprecated" :-)

> 3. Bei Grenzen kommt es darauf an, wie sie definiert sind.
> Wenn sie über unabhängige Koordinaten festgelegt sind, dann sollte 
> neue Objekte in OSM erstellt werden, die nicht verbunden sind 

:-)

> (bin mir nicht ganz sicher,
> vielleicht wäre es auch hier besser, eine von uns auf "unsere
> Lage-Realität" interpretierte Version der Grenze zu liefern, deren Verlauf
> zu dem Verlauf unserer Straßen und Flüsse passt?). 

Interessante Frage!
(wer definiert was genau und wie als "Realität"? und wie mappen wir
unterschiedliche Definitionen?)

> Wenn die Grenzbschreibungen dagegen über andere Objekte definiert sind,
> dann sollten sie auch in OSM über diese abgebildet werden.

Oft sind Grenzen "im Niemandsland": "hinter dem Gebirge"

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

Weder noch. Es besteht doch keinerlei Grund oder Zwang, entlang von
way's willkürlich Flachen zur Vereinfachung beim mappen aufzuteilen. Da
es in der Natür recht wenig Quadrate gibt, wäre in dem Fall vllt. ein
drüber gelegtes Gittermuster hilfreich, so bleibt dann lediglich die
äußere Grenze zur benachbarten Fläche Bearbeitungsschwerpunkt. Entlang
der Gitterlinien könnte man den Rest vereinfachen. Die Größe eines
solchen Gitters kann doch frei gewählt werden und ist lediglich - genau
wie die Aufteilung der Gesamtfläche - Hilfsmittel ohne Darstellung im
Rendering!

Gruß Sepp

Am 22.10.2018 12:41 schrieb Christoph Hormann:
> On Monday 22 October 2018, sepp1...@posteo.de wrote:
>> Wäre es das? Das Aufteilen der Flächen in handhabbare Größen sind
>> doch rein administrative und willkürliche Maßnahmen die so in der
>> Realität nicht vorhanden sind, dito Grenzen (egal welcher Art), auch
>> wenn es in den meisten Fällen eine Art Grenzbebauung oder
>> -bepflanzung gibt.
> 
> Ich bin mir nicht sicher, ob Du meine Annahme in Frage stellst, dass die 
> Aufteilung von Flächen anerkannte Mapping-Praxis ist oder ob Du denkst, 
> dass die Regel "Aufteilung ja, aber niemals entlang einer Straße" 
> unproblematisch wäre.

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

Re: [Talk-es] Qué poner en source cuando la fuente es una guía, catálogo o hemeroteca...

2018-10-22 Per discussione Santiago Crespo

Hola buenas Lanxana,

Si la Diputación de Girona se niega a firmar un permiso expreso, puedes
hacer una solicitud de información pública de acuerdo a la ley de
transparencia, acceso a la información pública y buen gobierno. De esta
forma estarán obligados a liberar la información sin las restricciones
que ponen en la web.

Dime si puedo ayudarte, tengo algo de experiencia haciendo estas
solicitudes.

Recordad que podéis hacer solicitudes de info pública a cualquier
administración en España, desde un Ayuntamiento al Estado.

Saludos,
Santiago Crespo

On 10/22/18 11:46 AM, Lanxana . wrote:
> Buenas,
> 
> estirando del hilo, he descubierto que la Diputación de Girona utilizó
> los datos recogidos en la guía para crear una página web [1] donde
> buscar por autor, obra, localidad... y actualizó los datos con las obras
> nuevas.
> 
> Problema, la web está bajo licencia 3.0, y cita textualmente (traduzco): 
> "La licencia autoriza la reproducción, distribución y comunicación
> pública de los contenidos, excepto para usos comerciales y siempre que
> se cite que las imágenes y los textos corresponden a la obra indicada en
> el encabezado. No se autoriza la realización de obras derivadas, como
> traducciones, adaptaciones o similares"
> 
> Igualmente voy a ponerme en contacto con ellos a través del formulario
> de la propia web, solicitando permiso expreso para el uso de los datos
> de nombre, autor y fecha en OpenStreetMap, así que crucemos los dedos.
> En todo caso ayer comencé el safari fotográfico capturando algunas. En
> algunos casos todos los datos están en la misma obra, en otros sólo el
> nombre del autor o la fecha y en otras nada de nada. Seguiré buscando
> fuentes alternativas...
> 
> En cuanto a los artículos del periódico, también he solicitado
> información sobre licencia y autorización expresa para su uso. 
> 
> Un saludo!
> 
> [1] http://www.ddgi.cat/escultures/
> 
> 
> El sáb., 20 oct. 2018 a las 19:35, dcapillae ( >) escribió:
> 
> Hola.
> 
> Me parece buena estrategia. La ubicación de las obras de arte
> público, así
> como sus eventuales nombres y seguramente sus autores, suelen ser de
> domino
> público. Si esa información se obtiene de fuentes válidas (autorizadas
> expresamente o compatibles con la licencia ODbL), del conocimiento
> local o
> por trabajo de campo propio (de un panel informativo en la calle, por
> ejemplo), no hay problema. Ahora bien, si esa misma información se
> obtiene
> de una fuente protegida por derechos de autor, la información podrá
> seguir
> siendo de dominio público, pero la fuente no nos sirve y no se puede
> citar
> como tal en OSM. Habría que obtener esa misma información a partir
> de otras
> fuentes, por otros medios, o pedir permiso.
> 
> Una página web cuyo contenido esté protegido por derechos de autor
> no sirve
> como fuente en OSM, ni siquiera si todo su contenido está disponible en
> dominio público a partir de otras fuentes. El dominio público permite
> reutilizar la información en obras derivadas bajo condiciones de
> licencia
> restrictivas, y en ese caso hay que respetar las nuevas condiciones de
> licencia. Si queremos usar la página web como fuente y el autor la tiene
> publicada bajo condición de «todos los derechos reservados»,
> tendremos que
> pedirle permiso.
> 
> 
> 
> -
> 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
> 

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

Re: [Talk-cz] historic=tomb se nerenderuje na Mapniku

2018-10-22 Per discussione Vladimír Slávik

Proč se nenajde třeba toto tím druhým dotazem, i když prvním ano? Něco tam
není úplně dobře...
https://www.openstreetmap.org/way/501707796
V+
-- Původní e-mail --
Od: majka 
Komu: talk-cz@openstreetmap.org
Datum: 19. 10. 2018 13:05:28
Předmět: Re: [Talk-cz] historic=tomb se nerenderuje na Mapniku
"
Nejlépe asi přes overpass turbo, wizard zafunguje pro většinu případů.
Konkrétně historic=tomb(https://overpass-turbo.eu/s/CVk) , je třeba najet na
odpovídající místo. Nebo by se daly vyhledat všechny v Čechách
(https://overpass-turbo.eu/s/CVl) (celkem 98 bodů)


On Fri, 19 Oct 2018 at 12:52, Pavel Pilát mailto:pavel.pi...@gmail.com)> wrote:

"
Lze mimochodem v OSM hledat přímo objekty s určitým tagem? Např. konkrétně
by mě zajímalo, kde je kolem Koryčan další nejbližší historic=tomb .


"

___
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-de] Androhung von Benutzersperren für Verklebe-Ideologie

2018-10-22 Per discussione Christoph Hormann

On Monday 22 October 2018, sepp1...@posteo.de wrote:
> Wäre es das? Das Aufteilen der Flächen in handhabbare Größen sind
> doch rein administrative und willkürliche Maßnahmen die so in der
> Realität nicht vorhanden sind, dito Grenzen (egal welcher Art), auch
> wenn es in den meisten Fällen eine Art Grenzbebauung oder
> -bepflanzung gibt.

Ich bin mir nicht sicher, ob Du meine Annahme in Frage stellst, dass die 
Aufteilung von Flächen anerkannte Mapping-Praxis ist oder ob Du denkst, 
dass die Regel "Aufteilung ja, aber niemals entlang einer Straße" 
unproblematisch wäre.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk-fr] Ces collectivités qui misent sur Openstreetmap et la cartographie participative

Un article de la Dépêche du Midi, mais l'image d'origine est du SDE09.

Pour les collectivités, c'est très bien qu'elles utilisent OSM, rien à
redire évidemment.
Qu'elles viennent expliquer que c'est sous leur initiative que les gens
viennent cartographier le territoire, pas du tout.
Il y a deux minimums qui me semblent essentiels avant toute
communication/auto-satisfaction/soirée petits-four :
- Partager les données dont elles sont responsables, nécessaires à nos
activités. C'est le meilleur moyen de soutenir nos initiatives il me semble.
- Respecter le travail d'autrui et les licences.
Ces deux objectifs ne sont pas atteints dans 90% des collectivités il
semblerait.

C'est ce qui me heurte dans l'article que tu as partagé, mais c'est aussi à
force d'avoir la tête dans le guidon que mon point de vue est probablement
déformé.

François

Le lun. 22 oct. 2018 à 12:12, Christian Quest  a
écrit :

> Là t'es un peu dur, c'est l'article de la Dépèche du Midi qui n'a pas mis
> d'attribution sur la carte.
>
> Possible qu'elle manque sur l'original... mais je ne sais pas où il est !
>
> Sur http://sde09.fr/50-vehicules-electriques.html on a une affreuse copie
> d'écran, mais en dessous c'est une carte Google...
>
>
> Le lun. 22 oct. 2018 à 12:03, François Lacombe 
> a écrit :
>
>> C'est une très bonne chose que les collectivités se saisissent de cet
>> outil et nous mettent en lumière par ailleurs.
>>
>> En parlant de mettre en lumière, la 1ere phrase est un peu étonnante.
>> Elle installe la confusion.
>> Depuis le début de l'histoire, c'est nous qui proposons aux collectivités
>> de mieux connaître leur territoire, en collectant des données locales et en
>> dépensant beaucoup d'énergie pour être considérés.
>> Même si ce n'est certainement pas politiquement correct voire tiré par
>> les cheveux ici, je serais bien vigilent à ce qu'ils ne retournent pas les
>> choses en leur faveur :)
>> C'est la communauté des citoyens qui produit une base de données de
>> qualité, et les collectivités comme la plupart des acteurs publics sont
>> bien à la traîne. Pas l'inverse, ce qu'on pourrait comprendre en lisant
>> l'article.
>>
>> En parlant de collectivités, certains oublient d'ailleurs de respecter
>> les termes de la licence.
>> C'est un oubli fâcheux, parce qu'elles connaissent déjà tellement bien
>> notre écosystème qu'elles peuvent se permettre de faire certains raccourcis.
>> https://twitter.com/InfosReseaux/status/1054307688677564418
>>
>> Bonne journée
>>
>> François
>>
>> Le ven. 19 oct. 2018 à 16:34, Christian Quest 
>> a écrit :
>>
>>> Article paru sur un site du Ministère de l’Economie, de l’Industrie et
>>> du Numérique...
>>>
>>>
>>> https://labo.societenumerique.gouv.fr/2018/10/17/collectivites-misent-openstreetmap-cartographie-participative/
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>> ___
>>> 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
>>
>
>
> --
> Christian Quest - OpenStreetMap France
> ___
> 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-de] Androhung von Benutzersperren für Verklebe-Ideologie

Wäre es das? Das Aufteilen der Flächen in handhabbare Größen sind doch 
rein administrative und willkürliche Maßnahmen die so in der Realität 
nicht vorhanden sind, dito Grenzen (egal welcher Art), auch wenn es in 
den meisten Fällen eine Art Grenzbebauung oder -bepflanzung gibt.


Gruß Sepp

Am 22.10.2018 11:27 schrieb Christoph Hormann:

On Sunday 21 October 2018, Frederik Ramm wrote:


Ich hab mal ins Blaue geschossen mit einem Entwurf:

https://wiki.openstreetmap.org/wiki/User:Frederik_Ramm/Fl%C3%A4chenve
rklebung

sowas in der Art könnte man ja mal fertigschreiben und dann abstimmen
und dann hat die leidige Diskussion vielleicht ein Ende...


Ich sehe ein gewisses Problem bei der Regel 2 in dem Fall, dass es
grundsätzlich als korrekt angesehen wird, wenn die Linie über die
Fläche gezeichnet wird - was zumindest bei kleineren Straßen und Tracks
im Wald allgemein anerkannt ist.  Da wir gleichzeitig die etablierte
Regel haben, dass Waldflächen und ähnliches in kleine, handhabbare und
ggf. ohne Multipolygone mapbare Stücke aufgeteilt werden können und
sollten, würde diese Regel im Grunde bedeuten: Man darf aufteilen, aber
niemals entlang einer Straße.  Das wäre dann ein bisschen schräg.


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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

Wie wäre es mit einr grafischen 2D-Darstellung des Problems, um es dem 
Neuuser auch bildlich zu verdeutlichen, was, wie, welche Auswirkungen 
hat und warum das ein oder andere eben nicht geht? Mir schwebt da eine 
einfache Grafik vor mit einem Querschnitt durch eine Straße mit 
angrenzender (Feld-)Fläche, Geh-/Radweg, kl. Grünstreifen und Bebauung. 
Das ganze aufgeteilt auf die Wertigkeit der Ebenen, d.h. landuse (egal 
in welcher Form) = Ebene 0, way's, buildings, etc. (also alles was drauf 
steht) = Ebene 1 und eben die Verbindungsmöglichkeiten einzelner Notes. 
Fehlt die Straßenfläche in Ebene 0, muss da eben eine Lücke bleiben, bis 
irgendwer die Fläche mappt.


Ich denke, der Neuuser und auch einige andere haben ein 
Vorstellungsproblem damit, dass der way in seinen unterschiedlichen 
Arten zwar grafisch anders dargestellt wird im Rendering, aber IMMER nur 
eine Linie ohne zugehörige Flächenausdehnung ist. In den Fall wird auch 
optisch klar, weshalb die Ackerfläche nicht die gleichen Notes nutzen 
kann, wie der way.


Ich bin nur blöderweise grafisch nicht bewandert, um das am Rechner 
darzustellen. Eine Skizze mit Zettel und stift könnte ich machen ;-)


Gruß Sepp



Am 22.10.2018 11:14 schrieb Martin Koppenhoefer:
der aktuelle Stand sieht sehr gut aus, 1, 2, 2.1 und 2.2. Da war ich 
mit

meiner vorherigen Mail nicht aktuell, Entschuldigung.

Wollen wir noch einen expliziten Paragraph für landuse einführen? Die
sollten m.E. auch besser nicht mit den highways verschmolzen werden 
(keine

Nodes teilen), wobei das Verwenden von highways für eine grobe
Ersterfassung schon ok ist (mit Multipolygonen kann man falsche
Verbindungen von highways vermeiden).

Gruß,
Martin
___
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] Ces collectivités qui misent sur Openstreetmap et la cartographie participative

2018-10-22 Per discussione Christian Quest

Là t'es un peu dur, c'est l'article de la Dépèche du Midi qui n'a pas mis
d'attribution sur la carte.

Possible qu'elle manque sur l'original... mais je ne sais pas où il est !

Sur http://sde09.fr/50-vehicules-electriques.html on a une affreuse copie
d'écran, mais en dessous c'est une carte Google...


Le lun. 22 oct. 2018 à 12:03, François Lacombe 
a écrit :

> C'est une très bonne chose que les collectivités se saisissent de cet
> outil et nous mettent en lumière par ailleurs.
>
> En parlant de mettre en lumière, la 1ere phrase est un peu étonnante. Elle
> installe la confusion.
> Depuis le début de l'histoire, c'est nous qui proposons aux collectivités
> de mieux connaître leur territoire, en collectant des données locales et en
> dépensant beaucoup d'énergie pour être considérés.
> Même si ce n'est certainement pas politiquement correct voire tiré par les
> cheveux ici, je serais bien vigilent à ce qu'ils ne retournent pas les
> choses en leur faveur :)
> C'est la communauté des citoyens qui produit une base de données de
> qualité, et les collectivités comme la plupart des acteurs publics sont
> bien à la traîne. Pas l'inverse, ce qu'on pourrait comprendre en lisant
> l'article.
>
> En parlant de collectivités, certains oublient d'ailleurs de respecter les
> termes de la licence.
> C'est un oubli fâcheux, parce qu'elles connaissent déjà tellement bien
> notre écosystème qu'elles peuvent se permettre de faire certains raccourcis.
> https://twitter.com/InfosReseaux/status/1054307688677564418
>
> Bonne journée
>
> François
>
> Le ven. 19 oct. 2018 à 16:34, Christian Quest  a
> écrit :
>
>> Article paru sur un site du Ministère de l’Economie, de l’Industrie et du
>> Numérique...
>>
>>
>> https://labo.societenumerique.gouv.fr/2018/10/17/collectivites-misent-openstreetmap-cartographie-participative/
>>
>> --
>> Christian Quest - OpenStreetMap France
>> ___
>> 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
>


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

Re: [OSM-talk-fr] Ces collectivités qui misent sur Openstreetmap et la cartographie participative

C'est une très bonne chose que les collectivités se saisissent de cet outil
et nous mettent en lumière par ailleurs.

En parlant de mettre en lumière, la 1ere phrase est un peu étonnante. Elle
installe la confusion.
Depuis le début de l'histoire, c'est nous qui proposons aux collectivités
de mieux connaître leur territoire, en collectant des données locales et en
dépensant beaucoup d'énergie pour être considérés.
Même si ce n'est certainement pas politiquement correct voire tiré par les
cheveux ici, je serais bien vigilent à ce qu'ils ne retournent pas les
choses en leur faveur :)
C'est la communauté des citoyens qui produit une base de données de
qualité, et les collectivités comme la plupart des acteurs publics sont
bien à la traîne. Pas l'inverse, ce qu'on pourrait comprendre en lisant
l'article.

En parlant de collectivités, certains oublient d'ailleurs de respecter les
termes de la licence.
C'est un oubli fâcheux, parce qu'elles connaissent déjà tellement bien
notre écosystème qu'elles peuvent se permettre de faire certains raccourcis.
https://twitter.com/InfosReseaux/status/1054307688677564418

Bonne journée

François

Le ven. 19 oct. 2018 à 16:34, Christian Quest  a
écrit :

> Article paru sur un site du Ministère de l’Economie, de l’Industrie et du
> Numérique...
>
>
> https://labo.societenumerique.gouv.fr/2018/10/17/collectivites-misent-openstreetmap-cartographie-participative/
>
> --
> Christian Quest - OpenStreetMap France
> ___
> 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-es] Qué poner en source cuando la fuente es una guía, catálogo o hemeroteca...

2018-10-22 Per discussione Lanxana .

Buenas,

estirando del hilo, he descubierto que la Diputación de Girona utilizó los
datos recogidos en la guía para crear una página web [1] donde buscar por
autor, obra, localidad... y actualizó los datos con las obras nuevas.

Problema, la web está bajo licencia 3.0, y cita textualmente (traduzco):
"La licencia autoriza la reproducción, distribución y comunicación pública
de los contenidos, excepto para usos comerciales y siempre que se cite que
las imágenes y los textos corresponden a la obra indicada en el encabezado.
No se autoriza la realización de obras derivadas, como traducciones,
adaptaciones o similares"

Igualmente voy a ponerme en contacto con ellos a través del formulario de
la propia web, solicitando permiso expreso para el uso de los datos de
nombre, autor y fecha en OpenStreetMap, así que crucemos los dedos. En todo
caso ayer comencé el safari fotográfico capturando algunas. En algunos
casos todos los datos están en la misma obra, en otros sólo el nombre del
autor o la fecha y en otras nada de nada. Seguiré buscando fuentes
alternativas...

En cuanto a los artículos del periódico, también he solicitado información
sobre licencia y autorización expresa para su uso.

Un saludo!

[1] http://www.ddgi.cat/escultures/


El sáb., 20 oct. 2018 a las 19:35, dcapillae ()
escribió:

> Hola.
>
> Me parece buena estrategia. La ubicación de las obras de arte público, así
> como sus eventuales nombres y seguramente sus autores, suelen ser de domino
> público. Si esa información se obtiene de fuentes válidas (autorizadas
> expresamente o compatibles con la licencia ODbL), del conocimiento local o
> por trabajo de campo propio (de un panel informativo en la calle, por
> ejemplo), no hay problema. Ahora bien, si esa misma información se obtiene
> de una fuente protegida por derechos de autor, la información podrá seguir
> siendo de dominio público, pero la fuente no nos sirve y no se puede citar
> como tal en OSM. Habría que obtener esa misma información a partir de otras
> fuentes, por otros medios, o pedir permiso.
>
> Una página web cuyo contenido esté protegido por derechos de autor no sirve
> como fuente en OSM, ni siquiera si todo su contenido está disponible en
> dominio público a partir de otras fuentes. El dominio público permite
> reutilizar la información en obras derivadas bajo condiciones de licencia
> restrictivas, y en ese caso hay que respetar las nuevas condiciones de
> licencia. Si queremos usar la página web como fuente y el autor la tiene
> publicada bajo condición de «todos los derechos reservados», tendremos que
> pedirle permiso.
>
>
>
> -
> 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

Re: [Talk-it] portoncino di ingresso

2018-10-22 Per discussione Federico Cortese

On Mon, Oct 22, 2018 at 10:12 AM Martin Koppenhoefer
 wrote:
>
> no, io mapperei barrier=gate quando c'è il cancello (più access=*), invece 
> quando si tratta di un'apertura senza barriere, si usa barrier=entrace.
>

Anche io userei solo barrier=gate.

Ciao,
Federico

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

2018-10-22 Per discussione Christoph Hormann

On Sunday 21 October 2018, Frederik Ramm wrote:
>
> Ich hab mal ins Blaue geschossen mit einem Entwurf:
>
> https://wiki.openstreetmap.org/wiki/User:Frederik_Ramm/Fl%C3%A4chenve
>rklebung
>
> sowas in der Art könnte man ja mal fertigschreiben und dann abstimmen
> und dann hat die leidige Diskussion vielleicht ein Ende...

Ich sehe ein gewisses Problem bei der Regel 2 in dem Fall, dass es 
grundsätzlich als korrekt angesehen wird, wenn die Linie über die 
Fläche gezeichnet wird - was zumindest bei kleineren Straßen und Tracks 
im Wald allgemein anerkannt ist.  Da wir gleichzeitig die etablierte 
Regel haben, dass Waldflächen und ähnliches in kleine, handhabbare und 
ggf. ohne Multipolygone mapbare Stücke aufgeteilt werden können und 
sollten, würde diese Regel im Grunde bedeuten: Man darf aufteilen, aber 
niemals entlang einer Straße.  Das wäre dann ein bisschen schräg.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

der aktuelle Stand sieht sehr gut aus, 1, 2, 2.1 und 2.2. Da war ich mit
meiner vorherigen Mail nicht aktuell, Entschuldigung.

Wollen wir noch einen expliziten Paragraph für landuse einführen? Die
sollten m.E. auch besser nicht mit den highways verschmolzen werden (keine
Nodes teilen), wobei das Verwenden von highways für eine grobe
Ersterfassung schon ok ist (mit Multipolygonen kann man falsche
Verbindungen von highways vermeiden).

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

[Talk-it] quartiere

2018-10-22 Per discussione Gabriele Sani

Buongiorno,
ho appena scoperto e risolto un errore nella mia citta' dove un neighborhood
aveva in qualche modo inglobato la citta' intera.

Come si mappa correttamente un quartiere/zona di una citta'?

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

Am So., 21. Okt. 2018 um 20:12 Uhr schrieb Frederik Ramm <
frede...@remote.org>:

> Hi,
>
> On 10/21/18 16:44, Martin Koppenhoefer wrote:
> > Aus meiner Erfahrung sehen das die meisten so, aber vermutlich mit dem
> Hintergedanken des Minderheitenschutzes, kann man sich z.B. in Deutschland
> bisher nicht auf ein Schema einigen und bevorzugt, beide Varianten zu
> empfehlen.
>
> Ich hab mal ins Blaue geschossen mit einem Entwurf:
>
>
> https://wiki.openstreetmap.org/wiki/User:Frederik_Ramm/Fl%C3%A4chenverklebung
>
> sowas in der Art könnte man ja mal fertigschreiben und dann abstimmen
> und dann hat die leidige Diskussion vielleicht ein Ende...

danke für die Initiative Frederik. Aus meiner Sicht greift das noch ein
bisschen kurz, weil es aus dem Verbinden eine grundsätzliche Frage ja oder
nein macht, es aber m.E. auf den Kontext ankommt.

1. Wenn 2 Flächen klar aneinandergrenzen, dann sollten sie m.E. gemeinsame
Nodes haben, also verbunden sein. Was man in Deutschland oft sieht, und was
die dt. Mapper zum Teil auch ins Ausland exportieren, sind Nodes die sehr
nahe aneinanderstehen (<1m) aber getrennte Nodes sind. Das sind m.E.
Topologiefehler, weil man aus den Daten m.E. explizit erkennen können soll,
ob 2 Flächen sich nur zufällig nahe kommen oder eine gemeinsame Grenze
haben (z.B. Friedhof der ohne Straße dazwischen an ein Wohngrundstück
angrenzt (Grenzmauer zwischen den beiden, typischerweise), 2 Gebäude die
angebaut sind, Gebäude die einen Platz begrenzen (Bezug ist also Platz und
Gebäude) etc.). Für diese Verbindung werden die Flächen an ihrer realen
Grenze gezeichnet, die "Berührungspunkte" jedoch gemeinsam mit den Nachbarn
genutzt.

1b. Flächen die an Linien grenzen. Hier würde ich es wie 1 sehen im Falle,
dass die Linie die Fläche begrenzt (es also nichts zwischen der Linie und
der Fläche gibt) und sie nicht zu breit ist (unter 50cm "Dicke"?) also die
begrenzende Linie z.B. eine Mauer oder ein Zaun ist, und die Fläche für das
Verbinden nicht merklich vergrößert werden muss.

2. Demgegenüber steht der andere Fall, wo die Mitte der Straßen (highway)
mit angrenzenden Flächen verbunden wird. Hierbei wird die Fläche
absichtlich vergrößert bis zur Mittellinie einer angrenzenden Straße (d.h.
Abstandsflächen, Entwässerungsflächen, Straßenränder und Straßenfläche
werden der angrenzenden Fläche zugeschlagen), um "leere Flächen" im
Rendering zu vermeiden. Dabei ergeben sich vielfältige topologische
Probleme, z.B. werden Dinge die am Straßenrand oder auf der Straße liegen
der angrenzenden Fläche zugeschlagen, die Begrenzung der Fläche (z.B.
Friedhofsmauer) läuft entweder nicht mehr am Rand des Friedhofs (wenn sie
an ihrer  realen Position bleibt) oder sie läuft in der Straßenmitte (wenn
sie am Rand der Fläche bleibt), etc. Das sollten wir m.E. als deprecated
ablehnen, weil es mühselig erweiterbar ist, rel. häufig zu Topologiefehlern
(fehlende Verbindungen) bei Straßen führt und weiterhin die Topologiefehler
(zuviel Dinge in der Fläche eingeschlossen) am Straßenrand sowie die
Vergrößerung der Flächen in Kauf nimmt.

3. Bei Grenzen kommt es darauf an, wie sie definiert sind. Wenn sie über
unabhängige Koordinaten festgelegt sind, dann sollte neue Objekte in OSM
erstellt werden, die nicht verbunden sind (bin mir nicht ganz sicher,
vielleicht wäre es auch hier besser, eine von uns auf "unsere
Lage-Realität" interpretierte Version der Grenze zu liefern, deren Verlauf
zu dem Verlauf unserer Straßen und Flüsse passt?). Wenn die
Grenzbschreibungen (es geht hier z.B. auch um Naturschutzgebiete, nicht nur
admin) dagegen über andere Objekte definiert sind, dann sollten sie auch in
OSM über diese abgebildet werden.

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

Re: [Talk-cz] OSMCZ na Mastodon

2018-10-22 Per discussione Miroslav Suchy

Dne 22.10.2018 v 09:56 Tom Ka napsal(a):
> Ahoj,
> 
> Mastodon je open source "nahrada" za Twitter a podobne. Narazil jsem
> na to, ze to OSM zkousi pozivat, tak jsem to zkusil taky. Nove tak
> budu promovat WeeklyOSM i zde:
> 
> https://mastodon.social/@osmcz

Ses si jistej, ze ten nick je spravny? Mala velka pismena?
Me to pise, ze neexistuje.

Mirek

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

[Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

2018-10-22 Per discussione Cascafico Giovanni

>> mappare nome volgare come genus:it?
> species:it?

Il dataset ha i campi nome scientifico e nome volgare. Ricapitolando dalla
wiki [1]:

species=* è il nome scientifico
genus=* è la prima parte del nome scientifico (ridondante se hai species)

quindi, per esempio da
species=Quercus robur L.

posso derivare
genus=Quercus

Ma il nome volgare "Farnia" dove lo metto? genus:it? La cosa che mi lascia
perplesso è che la wiki suggerisce "Please use the namespaces for local
languages" solo per il nome scientifico: che senso ha tradurre "Quercus
robur L."?

[1] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-fr] Rendu QA de retour...

2018-10-22 Per discussione Christian Quest

Il était HS depuis cet été, depuis le dernier plantage de SSD d'osm13 :(

J'ai enfin trouvé le temps de recharger les données annexes manquantes et à
jour (fantoir, carroyage insee, etc) pour que le rendu QA soit de nouveau
opérationnel.

Retour donc des carrés bleu et rose...

Légende dispo sur le wiki:
https://wiki.openstreetmap.org/wiki/FR:Serveurs/tile.openstreetmap.fr#Couche_.22Zones_.C3.A0_mapper.22

Retour aussi de pas mal d'analyses osmose liées à ces croisements
OSM/données externes.
-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] portoncino di ingresso

2018-10-22 Per discussione Simone Saviolo

Il giorno lun 22 ott 2018 alle ore 10:12 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

> no, io mapperei barrier=gate quando c'è il cancello (più access=*), invece
> quando si tratta di un'apertura senza barriere, si usa barrier=entrace.
>

barrier=entrance mi ha sempre fatto un po' strano: capisco da dove viene,
ma... non è una barriera :)

In ogni caso mapperei anche entrance=yes. Se vuoi accedere all'area, devi
passare da lì.

Ciao,

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

Re: [Talk-it] portoncino di ingresso