Re: [Talk-cz] Neexistující poštovní schránka v datech ČP?

[Michal Fabík]

2018-04-08 23:33 GMT+02:00 Miroslav Suchý :
> tehdy to určitě bylo v seznamu
> ...
> A pokud to není ani v seznamu ČP, tak jednoznačně smazat.

Smazáno. Právě jsem si nebyl jistý, jestli ještě někde neexistuje
nějaký seznam, ve kterém to je.

-- 
Michal Fabík

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

Re: [Talk-it] Mancata attribuzione

[Andreas Lattmann]

Trovata mail ed inviato richiesta attribuzione, ora rimango in attesa di 
risposte.

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [talk-au] bushtrax.com images

[forster]

Hi Keith

Thanks for your map contributions and for joining this discussion.
This discussion was about establishing general principles for the use  
of the viewpoint and image tags rather than any criticism of your  
specific edits.

No disrespect was intended to you or your website.

You say "Regarding the accuracy of the photos trust me you will have  
to drive to that point and have a look yourself"
There is no dispute about the accuracy or value of the photos, rather  
questions of whether to link to them in OSM and what object the link  
should be attached to.


Take two examples:
Node: River crossing (5536892190)
The photo contains valuable information on track conditions but it is  
not taken from a viewpoint "A place where tourists, visitors, hikers  
might like to visit and take photographs. A place, often high, with a  
good view of surrounding countryside or notable buildings. Sometimes  
called a vista point or scenic area/point, lookout or overlook"
The photo would have been better linked from the ford Node: 5536892207  
rather than creating a viewpoint.


Node: SE (5536892237)
Again this photo conveys valuable information about track conditions  
on the descent to the beach but is not taken from what can be  
described as a viewpoint. If anything, I think the photo should be  
linked to that section of track.


Tony


 I am the author of bushtrax.com and added those links to OSM. I also have
added quite a few 4wd tracks from the gpx files on the same site. As I have
found out another person has added one of those files under their name. I
just filled in all the relevant info.


Regarding the accuracy of the photos trust me you will have to drive to
that point and have a look yourself, I have been photographing the coast
using moving map software and a gps for nearly 17 years.

The viewpoint aspect is just that, I am standing on the Barron Lookout and
this is the view. I don't see the point of putting the viewpoint icon on
the road out the front of the Bremer Bay Caravan Park.

The tracks over time are realigned due to shifting dunes storms washing
them away or the managers of the land have deemed the track unsuitable and
altered the route. It also maps the rehabilitation that is carried out by
volunteers and the land managers staff. Some of the earliest efforts go
back as far as 1991, They are still there and in use today.


I have found plenty of these photos on other forums etc over the years but
they just used to link to the photo and left the photo on the server. No
problems from me. As in the case of of a Fairfax journalist who pinched one
early this year, he made himself look like fool.

Keith

Keith







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

Re: [OSM-talk] Villages with no highways

[john whelan]

Looking at the methodology in the associated blog it appears to include
villages that are connected with a path, track or tertiary highway and
since it was run in 2016 may possibly be a little out of date.

Can anyone think of a JOSM search that would pick them out?

Thanks John

On Sun, 8 Apr 2018 16:34 Frederik Ramm,  wrote:

> Hi,
>
> On 04/08/2018 10:16 PM, john whelan wrote:
> > If you look in parts of Africa there are a number of villages on the map
> > but no connecting highways.  Bing imagery is available for many of them
> > that show highways that connect them.
> >
> > Is there an easy way to pick them out?
>
> Not only that, someone has already picked them out:
>
> https://resultmaps.neis-one.org/unmapped#5/47.100/9.800
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Scritta gigante

[totera]

demon.box wrote
> ciao, come potrei mappare secondo voi questa scritta gigante con lettere
> alte
> almeno 3 metri?
> 
> http://gis.19327.n8.nabble.com/file/t339261/IMG_5191_%281024_x_768%29.jpg;
>  

Come https://www.openstreetmap.org/relation/1706337 forse? :)

Ciao,
Gianluca



--
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] Scritta gigante

[demon.box]

dieterdreist wrote
> https://wiki.openstreetmap.org/wiki/Key:advertising

sì c'avevo pensato anch'io ma con quale valore per una scritta del genere?

grazie

--enrico





--
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] Scritta gigante

[Martin Koppenhoefer]

sent from a phone

> On 9. Apr 2018, at 00:46, demon.box  wrote:
> 
> ciao, come potrei mappare secondo voi questa scritta gigante con lettere alte
> almeno 3 metri?


https://wiki.openstreetmap.org/wiki/Key:advertising


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

[Talk-it] Scritta gigante

[demon.box]

ciao, come potrei mappare secondo voi questa scritta gigante con lettere alte
almeno 3 metri?

 

grazie

--enrico




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

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

Re: [OSM-talk] [Osmf-talk] ODbL text

[Michael Kugelmann]

On 08.04.2018 at 14:12 Simon Poole wrote:
PS: that doesn't mean that having our own clean copy as a backup 
wouldn't be a good idea, 
I very much encourage the OSMF to host a copy of the license as the OSMF 
distributes their data (=> the raw OSM data)  using this license. This 
could be clearly marked as a copy with reference to the original one.


but IMHO the pointer to archive.org is probably the best of all bad 
solutions right now.
Is there a way to support open data commons / OKF with their problems 
(or maybe even make a *friendly* push to get their problems sorted out)?


BR,
Michael.


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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 22:40 Uhr
> Von: "Martin Koppenhoefer" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> das stimmt so nicht ganz, weil wenn ich eine Straße mit dem Acker auf der 
> linken Seite verbinde, und mit dem auf der rechten Seite, dann verbinde ich 
> auch die beiden Äcker miteinander, obwohl die gar nicht verbunden sind in der 
> Realität. D.H. zumindest die Komplexität fürs Auswerten ist nicht zu 
> unterschätzen, man könnte es aber auch als Fehler werten, je nach Definition.

+1, das stimmt.  Allerdings ist die Auswertung im anderen Modell auch nicht für 
alle Fragen einfach.  Wenn man den hybriden Aspekt mit der Zeit rauswachsen 
lassen will, muss man sich um eine Definition kümmern, welche z.B. die 
Verwendung von highway=* auf Flächengrenzen ausschließt.

Man schließt damit dann aber auch aus, Aspekte der Realität, wo das vielleicht 
wirklich doch genau so der Fall ist, gut zu modellieren.  Ich erinnere an 
Fußgängerüberwege, die keine sind, aber zu Routingzwecken eingemalt werden - 
das sind Geisterlinien, die keinen verifizierbaren Aspekt der Realität 
darstellen.  Die Gefahr besteht, dass sich so etwas Ähnliches dann wiederholt, 
wenn die Verwendung von highway=* ways programmatisch eingeschränkt wird.


Gruß

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 8. Apr 2018, at 23:43, Christian Müller  wrote:
> 
> Die Frage die sich stellt ist doch, ob das mehr an Linien dazu führt, dass 
> Mapper dann die Struktur der Daten eher/öfter richtig erfassen?


wenn diese Linien sich in der Realität jeweils gut erkennen lassen, dann bin 
ich da guter Hoffnung. Je abstrakter es ist, um so mehr Leute steigen aus.


Gruß,
Martin 



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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 22:21 Uhr
> Von: "Martin Koppenhoefer" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> im Prinzip unterschreibe ich das, nur dass ich die Befürchtung von Florian 
> teile, dass es im realen OSM-Alltag leicht in der Folge zu Topologiefehlern 
> kommt, weil viele Mapper die Struktur der Daten nicht richtig bzw. 
> vollständig erkennen.
> 
> Auch wenn man sowas z.B. mit JOSM extrem schnell zeichnen kann (einfach 
> schnell f drücken), ist das Resultat eigentlich nicht so einfach, obwohl es 
> aufgeräumt aussieht, und das wegen der mehrfachen überlappenden Linien.

Die Frage die sich stellt ist doch, ob das mehr an Linien dazu führt, dass 
Mapper dann die Struktur der Daten eher/öfter richtig erfassen?

Ich habe mittlerweile auch schon viele Flächenumrisse von Straßenkörpern 
gezeichnet, durfte mir aber mit der letzten Mail (an Florian) in Erinnerung 
rufen, dass die Verfügbarkeit der expliziten Straßengrenzen nicht in allen 
Fällen dazu führt, dass Flächen nicht mit der Mittellinie verbunden werden.  
Wenn es um gleichrangige Flächen geht, mag das so sein, aber eine 
Stadtbezirksfläche und damit -grenze wird man evtl. weiter mit der Mitte der 
Straße vernähen wollen, als mit der -kante.


Gruß

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 8. Apr 2018, at 23:32, Christian Müller  wrote:
> 
>  Und die
> verschiedenen Anwendungen, die Standardwerte für irgendwelche
> Breiten ungefähr annehmen gehören genauso zu OSM wie das doku-
> mentierte width-Tag.  OSM besteht nicht nur aus der DB!  Es
> ist ein verteiltes Ökosystem.


ich mir fällt ehrlich gesagt spontan keine einzige Anwendung im OSM Umfeld ein, 
die eine Straßenbreite annimmt (von abstrakten Breiten wie 2-spurig mal 
abgesehen). Hast Du mal ein Beispiel was Du damit meinst?

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

Re: [Talk-cz] Neexistující poštovní schránka v datech ČP?

[Miroslav Suchý]

Dne 8.4.2018 v 16:40 Michal Fabík napsal(a):
> dneska jsem si všiml, že schránka
> https://www.openstreetmap.org/node/4683791485 ve skutečnosti neexistuje.
> Na můj dotaz na vrátnici nemocnice jestli je _někde_ v areálu nemocnice
> poštovní schránka (tj. jestli tahle na zdi budovy třeba nebyla přesunuta
> někam dovnitř) mně bylo řečeno, že v nemocnici žádná schránka není a že
> byla zrušena cca před 4 lety. Podle historie změn
> (https://www.openstreetmap.org/node/4683791485/history) byla schránka
> přidána do mapy před cca rokem "dle seznamu ČP", čili je asi špatně ten
> seznam. V POI-Importeru na tomto místě žádná schránka označena není:
> http://osm.kyralovi.cz/POI-Importer-testing/#map=17/49.1841/16.5979=CZECPbox
> 
> Co s tím?

Já tam před půl rokem přidával ten ref (tehdy to určitě bylo v seznamu),
ale když jenom chyběl ref a bylo to v seznamu, tak jsem nekontroloval,
zda to tam reálně je. Ten jak Panorama tak StreetView ukazuje, že to tam
není. A pokud to není ani v seznamu ČP, tak jednoznačně smazat. Jdi to
toho! :)

Mirek


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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 21:15 Uhr
> Von: "Florian Lohoff" 
> An: "Christian Müller" 
> Cc: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> falscher wäre. Das einzige was eine valide Breite wäre wäre ein "width"
> tag das aber vernachlässigbare verbreitung findet und auch von
> keinem Datenkonsumenten ausgewertet wird.

"Don't bend the data", ja?  Just be patient.  Wie willst du auf der
Grundlage fehlender Daten argumentieren, dass die Linie nur etwas
/repräsentiert/, dass in der Realität gar nicht da ist??

Das ist absurd!  Und das ist so auch nicht dokumentiert.  Und die
verschiedenen Anwendungen, die Standardwerte für irgendwelche
Breiten ungefähr annehmen gehören genauso zu OSM wie das doku-
mentierte width-Tag.  OSM besteht nicht nur aus der DB!  Es
ist ein verteiltes Ökosystem.


> > Es ist eine Frage der Datenverwendung, ob der Linienzug und die assozi-
> > ierten Attribute zur Rekonstruktion der räumlichen Ausdehnung in 1, 2
> > oder 3 Dimensionen verwendet werden.
> 
> Nein - Man kann keine Tangente an einen Punkt konstruieren.

Niemand sprach von Punkten.  1 Dimension: Länge, 2 Dimensionen: Länge
plus Breite, 3 Dimensionen: Länge + Breite + Höhe

Verläuft der Straßenkörper annähernd gerade, reichen zwei Werte und eine
Linie um nach Belieben den ursprünglichen Körper rekonstruieren zu können,
je nachdem wieviele seiner Dimensionen für den Anwendungsfall benötigt
werden.


> Das ist jetzt nen bischen billig die Nummer. Es ist eben kein beliebiger
> extrusion algorithmus.

Doch ist es.  Simple is beautiful.  Komplizierter ist es für das 3D-
Mapping eigentlich auch nicht und das funktioniert schließlich bestens,
ohne die Lohoff'schen Einwände und Sorgen.  Es ist genauso nicht perfekt,
enthält abstraktionsbedingt Fehler, aber niemand kann und war darauf aus,
jeden Punkt der Realität in OSMs Datenbank abzubilden.


> Nein - Es prägt was mit den Daten möglich ist Mathematisch und was eben
> nicht - Und wenn dann Behauptungen in den Raum gestellt werden so wie
> von dir das das  ja "kein problem" sei oder "mathematisch nicht
> aufwendig" oder "problemlos" oder "allgemeine praxis" dann weiss ich
> daran schon das derjenige es nie selber probiert hat.

Du liest wahrscheinlich immer nur den Anfang meiner mails.  Es IST kein
Problem eine Fläche mit relativ konstanter Breite, die als Linie idealisiert
wurde mit der zugehörigen Breiteninformation unter Verwendung der Extru-
sionsmethode geometrisch zu reproduzieren.


> Ich bin echt müde dir jetzt aus einem OSM XML das auszurechnen das es
> günstiger ist weil dann kommt die nächste Schutzbehauptung und die
> nächste - Glauben ist halt das Gegenteil von Wissen. Vergleich dazu
> Gunkl und die Mondlandung.

Lächerlich, das ist doch selbst eine Schutzbehauptung!  Rechne es
doch einfach nach und trete damit an.


> talk-de ist vielleicht nicht der richtige Platz die Philosophischen
> Aspekte zu diskutieren die dir da jetzt so vorschweben.

?


> Es sind keine Momentaufnahmen sondern bezogen auf die Technischen Mittel
> des Eintragen möglichst genau zu erfassende Verifizierbare Daten.

Ja, die Erde ist eine Scheibe.  Amen.  Bei uns gab es mal einen Kirschbaum,
den konnte man recht lange verifizieren.  Heute steht da ein Poller.  An
anderer Stelle war mal eine Gärtnerei, da ist jetzt ne Tankstelle.  Alles
Momentaufnahmen, verifizierbar für kürzeste Zeit.  Die ganze Karte ist
eine Momentaufnahme und in bestimmten Details stets inaktuell.

Vielen Dank für deine Links, die ich alle sehr gut kenne.  Wie du
sehen kannst, können die kaum eindeutig sein, hätten wir doch hier
sonst keine Meinungsverschiedenheiten und würden im Gleichklang
tönen.

Momentaufnahmen sind verifizierbare Daten, für den Moment.


> Völlig irrelevant - Es geht nicht darum eine Fläche zu validieren 
> sondern es źu unterlassen absichtlich und aus purer Bequemlichkeit oder
> für den Renderer einen Fehler hinzuzufügen. 

Du verstehst es immer noch nicht.  Das was du als Fehler ansiehst,
ist in einem anderen Kontext kein Fehler.  Selbst die Ackergrenze
verschiebt sich von Jahr zu Jahr.  Willst du den Bauern jetzt auch
noch anhauen, dass der gerade fahren soll, damit du bei deiner Ein-
Meterdiskussion recht behältst?

Ohne Validierungsregel kann hier keiner behaupten, dass etwas
falsch ist, weil der (ich wiederhole mich..) /Bezugsrahmen/
nicht geklärt ist und eben auch nicht überprüft wird.

Du hast halt deinen Bezugsrahmen in dem das ein Fehler ist,
der nächste hat einen anderen, wo deine Linie einen Fehler
darstellt.  Es ist müßig darüber zu diskutieren.  Wenn du
hier so deinen Willen durchdrücken willst, dann darfst du
die Leute nicht anbetteln, dass so und so einzuhalten, son-
dern musst einen Regelsatz aufstellen, der serverseitig /über-
prüft/ bzw. validiert was auf den Server drauf darf und was
nicht.


> > Und im Prinzip sind Multipolygone und Boundaries derselbe Wein in
> > anderen Schläuchen.  Wenn man 

Re: [OSM-talk] Villages with no highways

[Pierre Béland]

My experience from all the humanitarian responses. Yes, it is important to know 
the territory and adapt. 
For the North of Mali humanitarian response in early 2013, people had 
difficulty to identify villages, flooded by water on the available images with 
the rainy season that last 6 months. In desertic regions it is also very 
difficult sometimes to spot houses if images are not clear enough.
For me this offers a good challenge, not to delete nodes but to find houses and 
add to OSM !
And yes, often, there are no roads in small african villages. Also in  some 
villages, we cannot identify what is private, what is public, and people walk 
in all directions. We need to observe an area, understand how it is organized.

 
Pierre 
 

Le dimanche 8 avril 2018 17 h 08 min 47 s HAE, Warin 
<61sundow...@gmail.com> a écrit :  
 
 In Papua New Guinea there are villages without roads ... people there travel 
by foot, plane or boat!

The terrain is such that vehicle roads, even for bicycles, is impractical.

I don't have detailed knowledge of Africa to say if these villages could be 
real or not... but I would hesitate to delete them without that knowledge.
Possibly question the original mapper or a mapper active locally or
failing any of that producing results demote them to locality and await a 
mapper with on ground experience.


On 09/04/18 06:31, Frederik Ramm wrote:
> Hi,
>
> On 04/08/2018 10:26 PM, Frederik Ramm wrote:
>> Not only that, someone has already picked them out:
> Looking a bit more at the list, I wonder if we should maybe delete all
> nodes that
>
> * were imported before 2010 from GNS
> * were never used since
> * have a "fixme=no population estimate available, defaulted to village"
> * and have no mapping in the vicinity
>
> I have the impression that many of these nodes are stranded in the
> wilderness between several, meanwhile-mapped, populated places, and the
> danger of getting lost while trying to reach one of these places might
> outweigh the advantage of having them.
>
> Bye
> Frederik
>


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

Re: [OSM-talk] Villages with no highways

[Warin]

In Papua New Guinea there are villages without roads ... people there travel by 
foot, plane or boat!

The terrain is such that vehicle roads, even for bicycles, is impractical.

I don't have detailed knowledge of Africa to say if these villages could be 
real or not... but I would hesitate to delete them without that knowledge.
Possibly question the original mapper or a mapper active locally or
failing any of that producing results demote them to locality and await a 
mapper with on ground experience.


On 09/04/18 06:31, Frederik Ramm wrote:

Hi,

On 04/08/2018 10:26 PM, Frederik Ramm wrote:

Not only that, someone has already picked them out:

Looking a bit more at the list, I wonder if we should maybe delete all
nodes that

* were imported before 2010 from GNS
* were never used since
* have a "fixme=no population estimate available, defaulted to village"
* and have no mapping in the vicinity

I have the impression that many of these nodes are stranded in the
wilderness between several, meanwhile-mapped, populated places, and the
danger of getting lost while trying to reach one of these places might
outweigh the advantage of having them.

Bye
Frederik




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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 8. Apr 2018, at 19:37, Christian Müller  wrote:
> 
> Nein, verkleben ist einfach nur die topologische Verbindung von zwei
> Objekten, die nebeneinander lieben.  Sie haben i.d.R. vor Ort eine
> gemeinsame Flächengrenze (sind also auch vor Ort verklebt).  Dass
> das in den Daten unrichtig wirkt(e) liegt an der Wahl der Repräsen-
> tation der geographischen Fakten


das stimmt so nicht ganz, weil wenn ich eine Straße mit dem Acker auf der 
linken Seite verbinde, und mit dem auf der rechten Seite, dann verbinde ich 
auch die beiden Äcker miteinander, obwohl die gar nicht verbunden sind in der 
Realität. D.H. zumindest die Komplexität fürs Auswerten ist nicht zu 
unterschätzen, man könnte es aber auch als Fehler werten, je nach Definition.

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 8. Apr 2018, at 19:37, Christian Müller  wrote:
> 
> Irgendwer hatte mal gemeint, dass man Flächen auch nur durch Punkte
> und Aussagen darüber, zu welchen Flächen diese Punkte gehören, modellieren
> kann  (also nicht nur flächengrenzbezogene Punkte, sondern auch innen
> liegende). Man rastert die Fläche also unregelmäßig mit fortschreitend
> mehr Samples, die Genauigkeit steigt mit der Anzahl der erfassten Punkte.
> 
> Das wird in OSM gar nicht verwendet, aber es ist denkbar, dass auch
> das mit der Zeit zu Ergebnissen führt, die mit den derzeit in OSM
> verwendeten Methoden konkurrieren können.


damals ging es um unscharfe Grenzen von geografischen Gebieten,  die man 
iterativ so definieren könnte indem man über einzelne, bereits vorhandene 
Objekte sagt was innerhalb und ggf. außerhalb liegt. Für diesen Anwendungsfall 
klingt das immer noch nach einem interessanten Ansatz.

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

Re: [OSM-talk] Villages with no highways

[Frederik Ramm]

Hi,

On 04/08/2018 10:26 PM, Frederik Ramm wrote:
> Not only that, someone has already picked them out:

Looking a bit more at the list, I wonder if we should maybe delete all
nodes that

* were imported before 2010 from GNS
* were never used since
* have a "fixme=no population estimate available, defaulted to village"
* and have no mapping in the vicinity

I have the impression that many of these nodes are stranded in the
wilderness between several, meanwhile-mapped, populated places, and the
danger of getting lost while trying to reach one of these places might
outweigh the advantage of having them.

Bye
Frederik

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

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

Re: [OSM-talk] Villages with no highways

[Frederik Ramm]

Hi,

On 04/08/2018 10:16 PM, john whelan wrote:
> If you look in parts of Africa there are a number of villages on the map
> but no connecting highways.  Bing imagery is available for many of them
> that show highways that connect them.
> 
> Is there an easy way to pick them out?

Not only that, someone has already picked them out:

https://resultmaps.neis-one.org/unmapped#5/47.100/9.800

Bye
Frederik

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

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

sent from a phone

> On 8. Apr 2018, at 19:37, Christian Müller  wrote:
> 
> Ich behaupte nicht, dass sich damit /in jedem Fall/ Flächenumrisse von Wegen 
> er-
> setzen oder perfekt rekonstruieren lassen, aber es ist oft gut genug und nie 
> topo-
> logisch falsch.


im Prinzip unterschreibe ich das, nur dass ich die Befürchtung von Florian 
teile, dass es im realen OSM-Alltag leicht in der Folge zu Topologiefehlern 
kommt, weil viele Mapper die Struktur der Daten nicht richtig bzw. vollständig 
erkennen. 

Auch wenn man sowas z.B. mit JOSM extrem schnell zeichnen kann (einfach schnell 
f drücken), ist das Resultat eigentlich nicht so einfach, obwohl es aufgeräumt 
aussieht, und das wegen der mehrfachen überlappenden Linien.

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

[OSM-talk] Villages with no highways

[john whelan]

If you look in parts of Africa there are a number of villages on the map
but no connecting highways.  Bing imagery is available for many of them
that show highways that connect them.

Is there an easy way to pick them out?

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

[Talk-cz] Kontrola účastníků workshopů

[Pavel Zbytovský]

Ahoj,

mohl bych poprosit o pomoc s kontrolou účastníků workshopů [1]?
Nově jsme začínali s tutoriálem v iD editoru, takže těch editací není tolik
- ale 30 lidí už něco poslalo. Stačí se samozřejmě mkrnout jen na
začátečníky.

Viz seznam lidí zde:
https://openstreetmap.cz/skoleni/stats?o=e

Zároveň otázka do pléna - jaké nástroje na kontrolu používáte? Vím že
existuje nějaký chytrý changeset browser, pak asi achavi na jednolivé
changesety?

Díky
Pavel


[1] https://openstreetmap.cz/skoleni/brezen18
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

Hola

On Sun, Apr 08, 2018 at 07:37:59PM +0200, "Christian Müller" wrote:
> Genau so, wie ein Routing-Graph /nur/ ein weiteres Beispiel ist, diese
> Datensammlung zu benutzen.  Weder das eine noch das andere wird idealer-
> weise bevorzugt.
> 
> Eigentlich ist es großer Mist, dass nur das credo
> "Wir mappen nicht für Renderer."
> so weit verbreitet ist, denn in gleicher Weise müsste sich
> "Wir mappen nicht für Routing-Engines."
> dazugesellen.

Das liegt daran das das einer der ganz ursprünglichen Maximen
von OSM ist und war:

https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_for_the_renderer

> > Wenn wir die Straße mit einer korrekten Breite erfassen
> > dann gibt es für den Straßenabschnitt 2 Objekte. Die Mittellinie als
> > geometrische Mitte der Straße mit allen Attributen wie
> > Geschwindigkeitsbeschränkung etc und eine Objekt mit der Ausdehnung -
> > Eine Highway Area.
> 
> Ja, das ist /jetzt/ so, /und/ es ist immer noch experimentell.  Es hat
> sich noch nicht überall durchgesetzt, dass die Erfassung der highway
> area sinnvoll ist; da gibt es noch viele Zweifelnde.

Auch das ist eine maxime der OSM 

https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_for_the_renderer

"They are continually improving, don't bend the data to make it
look prettier, just be patient. "

Und verkleben ist "bend the data" - Ganz einfach.

> Historisch gesehen wurde eine Straße eigentlich nur dort mit Flächen-
> umriss (also highway area) benutzt, wo eine konstante Breite des zu
> erfassenden Objekts fehlte.

Diese Konstante breite gibt es nicht in OSM - Die fügt Mapnik,
Osmarender, OsmAND, Mapbox  hinzu - Und zwar jeder so wie er will,
meint und je nach Zoomstufe und wie überrepräsentiert er gerne
Autobahnen möchte. OSM hat NIRGENDS eine Vorgabe wie breit ein
highway=unclassified ist.

Ich weiss nicht wie du drauf kommst das in OSM Linien eine Breite haben.

> > Korrekt - Die Mitellinie ist die Geometrische Mitte der Straße - Und die
> > erfassen wir. Dazu noch attribute der Straße - Mehr nicht.  
> 
> Sorry, aber das ist /deine/ Auffassung und vielleicht die ein paar anderer.
> Es ist so /nirgends/ dokumentiert und es ist auch nicht intuitiv (zumindest
> nicht, so lange der Flächenumriss nicht auch eingetragen ist - das ist noch
> lange nicht überall der Fall, auch wenn es in die Richtung geht, auf jeden
> Fall ist das ein Paradigmenwechsel).

https://wiki.openstreetmap.org/wiki/Good_practice#Keep_straight_ways_straight

"follow the central separation line between lanes in opposite directions
and add the relevant number of lanes in each forward/backward direction
for each section where the number of lanes changes"

Es ist alles seit >10 Jahren Dokumentiert das wir der zentralen
Mittellinie der Straße folgen. Das ist nicht MEINE Meinung das ist
Dokumentierte OSM Good Practice -  Kannst du zur Kenntnis nehmen
kannst es aber auch lassen und hier weiter trollen.

> Wir schrieben, dass eine Straße erfasst wird und die hat nunmal naturgemäß
> eine /Breite/, ob die nun explizit durch das width-Tag erfasst wird, oder
> mit größerem Fehler implizit durch lanes-Tags oder Klassifikationsattribute
> spielt weniger eine Rolle.

Auch die Lanes sind keine Breiteninformation - oder steht irgendwo das
eine lane 2,50m Breit ist? Nein - Explizit nicht weil soetwas noch viel
falscher wäre. Das einzige was eine valide Breite wäre wäre ein "width"
tag das aber vernachlässigbare verbreitung findet und auch von
keinem Datenkonsumenten ausgewertet wird.

> Es ist eine Frage der Datenverwendung, ob der Linienzug und die assozi-
> ierten Attribute zur Rekonstruktion der räumlichen Ausdehnung in 1, 2
> oder 3 Dimensionen verwendet werden.

Nein - Man kann keine Tangente an einen Punkt konstruieren.

> Das Routing-Engines nur die Ausdehnung in der Länge betrachten ist kein
> Grund zur Annahme, dass das Datenobjekt die Ausdehnung des geographisch-
> en Faktums in der Breite vernachlässigt.

Im Datenobjekt gibt es keine Breite - Wo siehst du die ? Mapnik
schummelt die da dran und das haben dir jetzt schon 3 Leute erklärt
und du weigerst dich dieses zur Kenntnis zu nehmen. Ich frage mich
langsam warum.

> > ich nicht einfach gedankenverloren Flächen an Wege geklebt weil das bei
> > egal welcher Genauigkeit einfach topologisch falsch ist und bleibt.
> 
> Ist es nicht.  Es ist maximal geometrisch ungenau, genau so ungenau, wie
> es eben ungenau ist, einen Weg als Linie und nicht als Fläche zu begreifen.

Du rundest eine absolute Position auf die nächste Straße - Damit ist
die absolute Position kaputt und zusätzlich topologisch falsch.

> > > Natürlich kann man das und es ist auch nicht so, dass das noch niemand 
> > > getan
> > > hätte oder die Algorithmen dazu nicht zur Verfügung stünden.  Ich habe 
> > > auch
> > 
> > Link? Referenz? 
> 
> Du kannst dich da beliebiger Extrusions-Algorithmen bedienen, also
> Algorithmen, die durch Parallelverschiebung der Kanten eines
> geometrischen 

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 09:56 Uhr
> Von: "Falk Zscheile" 
> An: "Openstreetmap allgemeines in Deutsch" 
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> 1. Durch die snap-Funktion im JOSM lassen landuse und highway viel
> leichter verbinden, als wieder trennen. Dadurch haben die
> "Verschmelzer" beim Mappen einen taktischen und zeitlichen Vorteil
> gegenüber den "Trennern".

Das mag in einzelnen Fällen entscheidend sein, imho aber ist der
Bequemlichkeitsaspekt entscheidender. Zudem scheint das Entklebe-
verhalten maßgeblich von der Verfügbarkeit hoch aufgelöster Luft-
bilder abhängig zu sein.  Man kann also auch an diesen Luftbildern
"kleben", ohne dass dies per se sinnbehafteter wäre.


Gruß

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 19:16 Uhr
> Von: "Florian Lohoff" 
> An: "Christian Müller" 
> Cc: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Ein Wasserweg bzw die Mitte dessen kann sehrwohl
> die Grenze darstellen. Eine Straße eher weniger (Hatte ich schon
> ausgeführt). Eine Straße kann aber nicht die Waldgrenze sein weil das
> bedingen würde das die Hälfte der Straße zum Wald gehört.

Oh, manchmal gehört die gesamte Straße zum Wald.  Alles eine Frage der
Perspektive und zeitlicher Entwicklungen:

A)  Die Baumkronen können die Straße vollends überdecken.

B)  Nach einem Unwetter, können zahlreiche Bäume auf der Straße liegen

C)  Auch Tiere gehören zum Wald, Tiere nutzen zeitweise die Straße, so
dass die strikten Übergänge verschwimmen.

D)  Forstarbeiter und Forstwirtschaftsmaschinen verwandeln die Straße
in einen Feldweg (ob saisonal oder über die Jahre).


> Hast du irgendeinen Beleg für? Ich bezweifle das stark. Der Normale mapper
> sieht nur nicht mehr was fehlt. Wenn du mir mal gegenden mit durchgehender
> sidewalk, shoulder, hazmat, maxspeed und lit mapping zeigst glaube ich das
> vielleicht.

Aber gerade das ist doch ein schönes Problem für eine gute Visualisierung,
die aufzeigt, wo solche Werte fehlen, oder eben lang nicht mehr bearbeitet
wurden.  Schwierig ist es, neue Mapper zu finden und zu motivieren.  Das
Problem teilt OSM mit Wikipedia.  Wenn die Leute dort ein paar Mal in einen
Editwar, Vandalismusdiskussionen und Admin-Gerichte über Relevanz verwickelt
waren, kommen sie halt nicht so schnell wieder oder senken Neugier und
Edit-Frequenz auf ein Minimum.


> Und in gegendenden in denen sich "jahrlang nichts mehr tut" ist die Karte
> so wie die in meiner E-Klasse von 2012 - Veraltet und echt nervig.

Ich finde es ganz gut, wenn ich von Zeit zu Zeit auf der Karte etwas
veraltetes entdecke.  Das motiviert von Zeit zu Zeit, etwas zu ergänzen.

Frustrierend ist doch eigentlich nur, wenn ein System so starr ist,
dass keine Edits möglich sind oder Kartenupdates erworben werden
müssen, wo dann immer noch die Hälfte fehlt.


Gruß

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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Christian Müller]

> Gesendet: Sonntag, 08. April 2018 um 10:00 Uhr
> Von: "Florian Lohoff" 
> An: "Christian Müller" 
> Cc: talk-de@openstreetmap.org
> Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
>
> Du scheinst aber hier dem Trugschluss aufzusitzen das OSM eine Karte
> ist. Das ist es nicht OSM ist und war nie eine Karte.

Du konntest unlängst selbst schlussfolgern, dass dieser Schein ein
Trugschluss ist, aber wenn man nur die Hälfte liest..


> OSM ist eine Sammlung von Geografischen Fakten. Die mit Mapnik erzeugte
> Karte ist nur ein Beispiel diese Sammlung an Fakten zu visualisieren.

Genau so, wie ein Routing-Graph /nur/ ein weiteres Beispiel ist, diese
Datensammlung zu benutzen.  Weder das eine noch das andere wird idealer-
weise bevorzugt.

Eigentlich ist es großer Mist, dass nur das credo
"Wir mappen nicht für Renderer."
so weit verbreitet ist, denn in gleicher Weise müsste sich
"Wir mappen nicht für Routing-Engines."
dazugesellen.

Und in beiden Statements müsste es lauten "nicht nur für".


> Wenn wir die Straße mit einer korrekten Breite erfassen
> dann gibt es für den Straßenabschnitt 2 Objekte. Die Mittellinie als
> geometrische Mitte der Straße mit allen Attributen wie
> Geschwindigkeitsbeschränkung etc und eine Objekt mit der Ausdehnung -
> Eine Highway Area.

Ja, das ist /jetzt/ so, /und/ es ist immer noch experimentell.  Es hat
sich noch nicht überall durchgesetzt, dass die Erfassung der highway
area sinnvoll ist; da gibt es noch viele Zweifelnde.

Historisch gesehen wurde eine Straße eigentlich nur dort mit Flächen-
umriss (also highway area) benutzt, wo eine konstante Breite des zu
erfassenden Objekts fehlte.


> Korrekt - Die Mitellinie ist die Geometrische Mitte der Straße - Und die
> erfassen wir. Dazu noch attribute der Straße - Mehr nicht.  

Sorry, aber das ist /deine/ Auffassung und vielleicht die ein paar anderer.
Es ist so /nirgends/ dokumentiert und es ist auch nicht intuitiv (zumindest
nicht, so lange der Flächenumriss nicht auch eingetragen ist - das ist noch
lange nicht überall der Fall, auch wenn es in die Richtung geht, auf jeden
Fall ist das ein Paradigmenwechsel).


> wievielten Mail zu sagen das wir bei Straßen ja eine Breite erfassen und
> das es schon okay ist Flächen damit zu verbinden weil man das ja "einfach raus
> rechnen kann". Und das ist halt in meinen Augen an so vielen Stellen 
> falsch das ich manchmal echt Baff bin. 

Es lässt sich rausrechnen mit abstraktionsbedingtem Fehler (Straßenweitungen
o.ä., Abschnitte nicht konstanter Breite über die Länge werden halt begradigt).
Dass es einfach ist habe ich nicht gesagt, denn das liegt im Auge des Be-
trachters, bzw. bei denjenigem, der es umsetzt.

Wir schrieben, dass eine Straße erfasst wird und die hat nunmal naturgemäß
eine /Breite/, ob die nun explizit durch das width-Tag erfasst wird, oder
mit größerem Fehler implizit durch lanes-Tags oder Klassifikationsattribute
spielt weniger eine Rolle.

Wir erfassen nicht die /Mittellinie der Straße/, sondern die Straße als
Linie.  Das ist nunmal ein Unterschied.

---
Das geographische Faktum, das erfasst wird, ist die Straße und /nicht/
deren Mittellinie, wie von dir oben behauptet.  Man hat sich entschieden,
dieses Faktum in der Datenbank als Linienzug zu /repräsentieren/.  Das
Faktum hingegen besitzt eine räumliche Ausdehnung in /Länge/, /Breite/
und /Höhe/, wie die eigentliche Mittellinie der Straße vor Ort im Übrigen
auch (aber die ist eben /nicht/ das modellierte Faktum!).
---

Es ist eine Frage der Datenverwendung, ob der Linienzug und die assozi-
ierten Attribute zur Rekonstruktion der räumlichen Ausdehnung in 1, 2
oder 3 Dimensionen verwendet werden.

Das Routing-Engines nur die Ausdehnung in der Länge betrachten ist kein
Grund zur Annahme, dass das Datenobjekt die Ausdehnung des geographisch-
en Faktums in der Breite vernachlässigt.

Ginge es nur darum, einen Routing-Graphen zu erstellen, könnte man sich
noch viel mehr Details sparen:  Dazu musst du die Straße eigentlich nur
mit Anfang- und Endpunkt und evtl. durch Punkte bei Geschwindigkeits-
wechseln erfassen und die Abschnitte dann mit der Distanz versehen bzw.
gewichten.  Dieser Anwendungsfall benötigt viel weniger geographische
Fakten, als in OSM erfasst werden / sind.


> Ein 1 Dimensionales Objekt kann nie eine reale Breite haben.

Was gleichzeitig bedeutet, dass ein 1-dimensionales Objekt nicht real
sein kann!?  Es ist eben eine Idealisierung, dass der Darstellung und
Speicherung von /Abbildern/ geographischer Fakten dient, die immer
eine räumliche Ausdehnung haben (und oft eine zeitliche noch dazu).

Selbst die Mittellinie der Straße hat im übrigen eine räumliche Aus-
dehnung in drei Dimensionen, aber dieser geographische Fakt wird in
der DB /nicht/ beschrieben (zumindest nicht von DB-Objekten mit
assoziierten highway=* Werten).


> ich nicht einfach gedankenverloren 

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

On Sat, Apr 07, 2018 at 10:40:07PM +0200, "Christian Müller" wrote:
> Deine Argumentation basiert im großen Teil darauf, dass es eine Last wäre,
> Bestandsdaten zu editieren, wenn um die Neudaten herum, schon Bestand ex-
> istiert, der miteditiert werden muss.  Niemand zwingt Mappende, bei OSM

Verklebte Daten zu editieren ist eine große Last ja.


> Du hängst dich zwar an dem "Verklebt-Sein" zwischen linearen und arealen
> Objekten auf, aber die Implikation ist viel weitreichender:  Die Grenzen
> von Ländern und Bundesländern waren recht zeitig gemappt (ohne "unschöne"
> Lücken an den Landesgrenzen - weiß nicht, ob du auch dort Lücken lassen
> würdest).  Diese Grenzen aber bilden Flächen.  Der Leerraum oder der
> "weiße Fleck" den du also auf hoher Zoomstufe identifiziert haben wolltest,
> war zu diesem Zeitpunkt schon längst von einer Fläche überstrichen, zu
> dem Du in diese Fläche eine weitere eingezeichnet hattest.  Quizfrage:

Du ziehst hier ein Beispiel heran um das es nicht geht. Grenzen sind ein
absoluter Sonderfall. Ein Wasserweg bzw die Mitte dessen kann sehrwohl
die Grenze darstellen. Eine Straße eher weniger (Hatte ich schon
ausgeführt). Eine Straße kann aber nicht die Waldgrenze sein weil das
bedingen würde das die Hälfte der Straße zum Wald gehört.

Das am Beispiel einer Grenzrelation zu machen ist so ein bischen Äpfel
mit Birnen zu vergleichen und war auch nicht bestandteil 
der Verklebediskussion.

> Die "Last" Flächen neu zu mappen oder umzumappen entsteht regelmäßig
> u.a. dann, wenn ein Paradigmenwechsel durch Wiki oder Mailingliste
> fegt, und dazu führt, dass Daten, die früher unter einem anderen
> Paradigma eingetragen wurden, plötzlich ihre Gültigkeit verlieren
> (beispielhaft weil Teiche in einem Forst nicht mehr Teil der Forst-
> fläche sein sollen und als 'inner' von umliegenden Waldflächen aus-
> genommen werden, etc. pp.).  

Die Last entsteht immer dann wenn sich eines der verklebten Elemente
ändert, das andere jedoch nicht. D.h. z.b. ich will die Ackerfläche verkleinern
um einen Straßengraben anzufügen. Dann habe ich ein vielfaches des
aufwandes weil ich jeden node "unglueen" muss - dann die ja typischerweise
mind. 3 nodes sortieren (Straße, rechter und linker landuse) und dann ggfs
2 der nodes wieder verschmelzen.

Und das volldesaster entsteht dann wenn ein Mapper nichtmal merkt das es dort
verklebungen gibt. Das kommt relativ häufig vor.  Dann wird zwar ein node
weggezogen auf eine vermeindlich bessere lage, das passt aber dann nicht mehr
zu einem der verbundenen Objekte.  Der Nächste Mapper sieht im Luftbild ein
Objekt zu dessen Form es aber kein OSM Objekt mehr gibt und malt es drüber.

Das ist quasi bei dem Aufräumen eine Tägliche Routine. Doppelt und Dreifach
übereinander und verklebte Gebäude, Parkplätze etc.

> Ich stimme hier mit dir überein, ich sehe es auch ungern, wenn ungeduldige
> Mapper gigantische Flächen mit einem einzigen Tag beschreiben, nur damit
> die Karte nicht mehr weiß ist.  Allerdings sehe ich es nicht als Problem
> an, solche Flächen zu überarbeiten - in Iteration lassen sich in eine
> solche Fläche (ähnlich den oben erwähnten Ländergrenzen) kleinere Objekte
> einzeichnen ("mit Lücken dazwischen"), die dann mit der Zeit verbunden
> und in Relation gesetzt werden.  Dabei kann es vorkommen, dass vorher
> eingetragene Flächengrenzen segmentiert werden.

Das ist aber gigantisch viel aufwendiger wenn das noch alles verklebt ist.
Mal davon abgesehen das die ursprüngliche Fläche auch "mapping für den renderer"
ist was explizit unerwünscht ist.

> Eine detaillierte Karte entsteht nicht über Nacht, das braucht Zeit.
> Ob in der Zwischenzeit Details von Monsterflächen verdeckt werden,
> die dann wieder verschwinden (oder als benannte, komplexe Fläche
> mit Teilflächen, z.B. Muskauer Park fortbestehen), ist doch im Grunde
> weniger wichtig.

Es ist extrem wichtig. Denn solche gigantischen Flächen fast niemand mehr an. 
Die werden gemapped und ich sehe das die 10 Jahre Später quasi unverändert
da noch rumschimmeln weil sich da keiner dran traut. Das ist eines der 
Folgeprobleme
des verklebens. Es erhöht die komplexität der vorhandenen Daten und damit
sinkt die wahrscheinlichkeit der weiteren Pflege.

> Das kann man so pauschal nicht sagen.  Wäre es so dramatisch, wie du es
> darstellst, gäbe es viel weniger Nutzung etablierter Tags und wesent-
> lich häufiger Streit um irgendwelche Changesets.  Die Änderungsdichte

Normative Kraft des faktischen. Menschen wollen das die gerenderte Karte schön
aussieht also wird gemapped und getagged was funktioniert.
OSM hat ein typischer EDV Problem auf den Kopf gestellt. Nicht die Eingabe 
validiert
und bestimmt das schema sondern die weitere verarbeitung. Wenn ich möchte das
meine Adresse in Nominatim auftaucht muss ich das Karlsruhe Schema nehmen.

> wäre schlicht eine größere, aber in vielen Gebieten tut sich schon
> jahrelang nichts (wesentliches) mehr, weil die Daten, so wie sie ein-
> getragen sind, weitgehend 

[Talk-GB] FOSS4G travel grants

[Rob Nickerson]

Please note that grants are available for FOSS4G:

https://www.osgeo.org/initiatives/foss4g-travel-grant-program/

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

Re: [Talk-cz] osmap.cz v0.20 + talkcz online

[Pavel Zbytovský]

Bohužel tam ten mail-listový software hodí natrvdo odřádkování, to bohužel
nelze nijak rozpoznat.

Ale řešili jsme s Vopem, že je to naše talkcz-kukátko docela praktická
funkce, tak bych se možná pokusil nasát tam maily v HTML podobě. A pak už
by to odkazy nemrvilo a hlavně by byly funkční ty citace...
Akorát moc nevím jak to udělat, než tak, že si vytáhnu příslušené zprávy z
archivu svého gmailu... Což bude docela dřina naprogramovat.

btw, talkcz-kukátko má za první kvartál docela slušnou návštěvnost:
Path Pageviews
1. / 8,772(50.26%)
2. /skoleni/ 1,080(6.19%)
3. /talkcz/ 1,068(6.12%)
4. /vyuziti 868(4.97%)
5. /offline-mapa-android 690(3.95%)
6. /splash 471(2.70%)
7. /galerie 392(2.25%)
8. /live/ 385(2.21%)
9. /node/ 322(1.85%)
10. /turistika 308(1.76%)
 celkem: 17,452(100%)
(A kdybyste se někdo chtěl vrtat v google analytics, napište mi maila - rád
tam rozdám přístupy)

Pavel



On Fri, Mar 2, 2018 at 8:51 AM Marián Kyral  wrote:

>
> -- Původní e-mail --
> Od: Pavel Zbytovský 
> Komu: OpenStreetMap Czech Republic 
> Datum: 8. 1. 2018 17:40:04
> Předmět: [Talk-cz] osmap.cz v0.20 + talkcz online
>
> Ahoj,
>
> oznámený update verzí openstreetmap.cz doběhl, zdá se, úspěšně.
>
> Nyní tedy máme osmcz-app v0.20, tj.:
> - "tajný" marker (aka ten na osm.org) má navíc parametr = se zprávou
> - gp-check - nový form pro chybějící rozcestník
> - úpravy kódu viz [1]
>
> Zároveň je spuštěn archiv konference talkcz na adrese
> https://osmap.cz/talkcz/
> (Podrobně viz [2], též proběhla úprava mergování app do website)
>
> Případné chyby prosím hlašte :-)
> Pavel
>
>
> Ahoj,
>
> dlouhé odkazy dělají krapet problémy:
>
> https://openstreetmap.cz/talkcz/c2406#m8c112c
>
>
>
> Nekoukal jsem, jak to zpracováváš, ale tipuji, že zalomené to už dostaneš
> že?
>
>
> Marián
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Martin Koppenhoefer]

> On 8. Apr 2018, at 10:00, Florian Lohoff  wrote:
> On Sun, Apr 08, 2018 at 02:57:34AM +0200, "Christian Müller" wrote:
>>> Gesendet: Sonntag, 08. April 2018 um 00:43 Uhr
>>> Von: "Florian Lohoff" 
>> 
>> Wenn das width-tag fehlt, wird je nach
>> Straßenklasse und evtl. dem lanes-Attribut eine Breite errechnet.


sorry, errechnet wird da dann gar nichts, es wird geraten / geschätzt, weil man 
ja auch mit lanes getaggt keine Angaben zur Spurbreite hat, genauso wenig wie 
Straßenklassen feste Breiten haben.



> 
> Nur und ausschliesslich im Renderer und das auch nur Renderer Spezifisch
> und das auch in Pixeln je nach Auflösung - Mit der realen Breite hat und
> hatte das nie zu tun.
> 


es war mit mapnik lange Zeit nicht möglich, Stileigenschaften parametrisch zu 
definieren (z.B. die Linienbreite aus der Datenbank zu nehmen), soweit ich weiß 
geht das jetzt aber. In Qgis geht es z.B. sicher.



> Ein 1 Dimensionales Objekt kann nie eine reale Breite haben. Die wird an
> den Stellen wo die Straße angezeigt wird nur dazu geschummelt. Mit Real
> erfasster Breite hat und hatte das nie zu tun und wird es auch nie zu
> tun haben. Wenn du eine Reale Fläche/Breite haben willst musst du das
> als Fläche separat erfassen.



solange die Breite unverändert gleich bleibt geht es schon mit einer Linie und 
Breitenangabe, nur wenn die Breite sich halt ändert wird es schwierig. Plätze 
waren in OSM z.B. historisch sehr lange schlecht repräsentiert/abbildbar, quasi 
waren sie zunächst vergessen worden, weil es eben um die Verbindungen ging, und 
weniger um die Form.


> Hat aber auch alles nichts mit der Genauigkeit zu tun. Auch damals habe
> ich nicht einfach gedankenverloren Flächen an Wege geklebt weil das bei
> egal welcher Genauigkeit einfach topologisch falsch ist und bleibt.



so hart würde ich es nicht sagen, weil man m.E. durchaus auch für das Verbinden 
argumentieren könnte, wenn es vorwiegend um ein vereinfachtes Topologiemodell 
ginge und man keine Details unterhalb des landuse levels hätte und wollte.

Ich kenne OSM auch noch aus Zeiten vor der Verfügbarkeit von guten Luftbildern, 
als man noch ausschließlich mit Notizen, Fotos und GPS gearbeitet hat, bzw. gab 
es schon grobpixelige Yahoo bilder mit zig Metern Lageungenauigkeit (und es gab 
Mapper, die alles mühsam erarbeitete auf diesen Luftbildern „zurechtschob“, 
ähnlich wie heute mit Bing, nur auf anderem Video), und ich war auch damals 
schon dagegen , beim Flächenzeichnen eine Abkürzung zu nehmen, von der klar 
war, dass sie das Eintragen von weiteren Details ziemlich erschweren würde.


>> (OSM war
>> /ist ein Hobbyprojekt, ein Projekt von und für die crowd nicht wahr?)
> 
> Also bisher hatte ich immer (>10 Jahre) die Möglichkeit auf Rechnern zu
> Arbeiten die die OSM Daten verarbeiten konnten. Ich habe lange für QA
> Zwecke OSRM Instanzen laufen gehabt die den ganzen Tag routen getestet
> haben etc. Ich habe mal ein auf PostgreSQL/PostGIS basierendes Datenbankend 
> für 
> osmarender gebaut. So abwegig ist das mit den OSM Daten zu arbeiten nicht.


+1, es ist (war) eher die Komplexität der einzelnen tools und Abhängigkeiten 
und der Aufwand, alles mögliche einzurichten, die viele m.E. davon abgehalten 
haben, selbst Dinge mit den Daten zu machen, als die Hardwareanforderungen. 
Hobbyisten haben meistens keinen Bedarf an weltweiten detaillierten Daten, 
vielen reicht ein regionales Gebiet aus für ihre Bedürfnisse (danke Geofabrik 
und andere), und das dauert selbst auf schmalbrüstiger, veralteter 
Konsumerhardware nicht soo lang, das durchzuwursten.

Auch wenn für sich genommen die einzelnen Schritte nicht so schwer sind, so 
sind es oft doch einige. Es gibt und gab aber immer auch schon rel. simple 
tools (in der Bedienung ) mit denen man schon sehr viel machen kann, z.B. 
maperitive, osmarender, overpass turbo, und mittlerweile sind auch klassische 
GIS tools wie QGis gut auf OSM vorbereitet.


> 
>> Das Verkleben ist im Hinblick darauf, die Größe der DB klein zu halten,
>> heute scheinbar nicht mehr so wichtig.  Vor zehn Jahren gab es schon noch
>> ein paar mehr Leute, denen es wichtig war, dass die Gesamtdaten auch auf
>> kleine Geräte passten und dort verarbeitbar waren.  


um die Daten auf kleine Geräte zu packen kann man sie bearbeiten / filtern und 
bei Bedarf die Genauigkeit reduzieren. Das sollte kein Argument sein, um 
absichtlich weniger in die db einzutragen als man eigentlich gut fände.


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

[talk-au] bushtrax.com images

[K C]

 I am the author of bushtrax.com and added those links to OSM. I also have
added quite a few 4wd tracks from the gpx files on the same site. As I have
found out another person has added one of those files under their name. I
just filled in all the relevant info.


Regarding the accuracy of the photos trust me you will have to drive to
that point and have a look yourself, I have been photographing the coast
using moving map software and a gps for nearly 17 years.

The viewpoint aspect is just that, I am standing on the Barron Lookout and
this is the view. I don't see the point of putting the viewpoint icon on
the road out the front of the Bremer Bay Caravan Park.

The tracks over time are realigned due to shifting dunes storms washing
them away or the managers of the land have deemed the track unsuitable and
altered the route. It also maps the rehabilitation that is carried out by
volunteers and the land managers staff. Some of the earliest efforts go
back as far as 1991, They are still there and in use today.


I have found plenty of these photos on other forums etc over the years but
they just used to link to the photo and left the photo on the server. No
problems from me. As in the case of of a Fairfax journalist who pinched one
early this year, he made himself look like fool.

Keith

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

[Talk-cz] Neexistující poštovní schránka v datech ČP?

[Michal Fabík]

Ahoj,
dneska jsem si všiml, že schránka 
https://www.openstreetmap.org/node/4683791485 ve skutečnosti neexistuje. 
Na můj dotaz na vrátnici nemocnice jestli je _někde_ v areálu nemocnice 
poštovní schránka (tj. jestli tahle na zdi budovy třeba nebyla přesunuta 
někam dovnitř) mně bylo řečeno, že v nemocnici žádná schránka není a že 
byla zrušena cca před 4 lety. Podle historie změn 
(https://www.openstreetmap.org/node/4683791485/history) byla schránka 
přidána do mapy před cca rokem "dle seznamu ČP", čili je asi špatně ten 
seznam. V POI-Importeru na tomto místě žádná schránka označena není: 
http://osm.kyralovi.cz/POI-Importer-testing/#map=17/49.1841/16.5979=CZECPbox

Co s tím?

--
Michal Fabík

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

Re: [OSM-talk-fr] [OSM transport] Modifications en masse en Ile de France sur le réseau de TeC

[Antoine Riche]

Il s'agit de la 2e contribution de cet utilisateur, réalisée avec 
Maps.me. Je lui ai envoyé un message directement, mais s'il n'utilise 
que Maps.Me il risque pas de le voir.
Les premiers commentaires ont déjà 8 jours, je n'attendrais pas beaucoup 
plus pour faire un revert. Qu'en pensez-vous ?

Antoine.

Le 07/04/2018 à 23:54, Donat ROBAUX a écrit :

Pour moi c'est revert si pas de réaction d'ici 2 semaines.

Donat

 
	Garanti sans virus. www.avast.com 
 




Le 5 avril 2018 à 21:49, George Kaplan > a écrit :


Bonjour,

Un nouveau contributeur vient d’apporter de nombreux changements
sur les réseaux de transports en Ile de France. De nombreux si ce
n’est la totalité des changements apportés sont mal taggués ou
incorrects. Le changeset se trouve là :
https://www.openstreetmap.org/changeset/57693634


Plusieurs contributeurs ont réagi via des commentaires mais pas de
retour du contributeur original en 5 jours.

Des avis ?

George






---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-au] Talk-au Digest, Vol 130, Issue 4

[K C]

https://www.bushtrax.com site is copyrighted so I assume that such
> > links to the photos need to be either accompanied by permission or
> > disclaimer or suitable licence or display of the copyright, etc from the
> > copyright holder.
> > Does anything need to be documented on this page
> > https://wiki.openstreetmap.org/wiki/Contributors#Australia.
> > Or is any url from the web of an image ok to be pasted without any
> further
> > consideration other than relevance?
> > Nev
> >
> >
> >
> > ___
> > Talk-au mailing list
> > Talk-au@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-au
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <http://lists.openstreetmap.org/pipermail/talk-au/
> attachments/20180408/476bfa4b/attachment-0001.html>
>
> --
>
> Message: 4
> Date: Sun, 08 Apr 2018 13:04:10 +1000
> From: fors...@ozonline.com.au
> To: nwastra <nwas...@gmail.com>
> Cc: OSM - Talk-au <Talk-au@openstreetmap.org>
> Subject: Re: [talk-au] tagged links to photos
> Message-ID: <20180408130410.m5n9ckfty8cw0...@webmail2.ozonline.com.au>
> Content-Type: text/plain;   charset=ISO-8859-1; DelSp="Yes";
> format="flowed"
>
> Nev
>
> My guess is that its OK to link to copyright data without any
> disclaimer. I do however have concerns about the verifiability of
> these nodes and relevance of the images.
>
> Would we identify these locations as viewpoints? I doubt it.
>
> The images are not of the mapped feature, they are from the viewpoint
> not of the viewpoint.
>
> Tony
>
> > Are we free to add tag links to images to OSM as in this.
> > http://overpass-api.de/achavi/?changeset=57903447
> > The https://www.bushtrax.com site is copyrighted so I assume that
> > such links to the photos need to be either accompanied by permission
> >  or disclaimer or suitable licence or display of the copyright, etc
> > from the copyright holder.
> > Does anything need to be documented on this page
> > https://wiki.openstreetmap.org/wiki/Contributors#Australia.
> > Or is any url from the web of an image ok to be pasted without any
> > further consideration other than relevance?
> > Nev
> >
> >
> >
> > ___
> > Talk-au mailing list
> > Talk-au@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-au
> >
> > _
> > This mail has been virus scanned by Australia On Line
> > see http://www.australiaonline.net.au/mailscanning
> >
>
>
>
>
>
>
>
> --
>
> Message: 5
> Date: Sun, 8 Apr 2018 14:09:11 +1000
> From: nwastra <nwas...@gmail.com>
> To: OSM - Talk-au <Talk-au@openstreetmap.org>
> Subject: [talk-au]  tagged links to photos
> Message-ID: <8e1977d1-db47-4c90-9a32-4b1073a49...@gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> A GoogleMaps image is ok too?…when they are of of a mapped feature (and
> not used to map the feature)? or is this different?
> https://www.google.com.au/maps/@-33.9560741,119.9166289,
> 3a,75y,90t/data=!3m8!1e2!3m6!1sAF1QipM_Vhku1tFjnVrw8FDsYSYLFmw0Evpu6U
> sVGGQ1!2e10!3e12!6shttps:%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipM_
> Vhku1tFjnVrw8FDsYSYLFmw0Evpu6UsVGGQ1%3Dw203-h114-k-no!7i5344!8i3006
>
> >
> >> Are we free to add tag links to images to OSM as in this.
> >> http://overpass-api.de/achavi/?changeset=57903447
> >> The https://www.bushtrax.com site is copyrighted so I assume that
> such links to the photos need to be either accompanied by permission  or
> disclaimer or suitable licence or display of the copyright, etc  from the
> copyright holder.
> >> Does anything need to be documented on this page
> https://wiki.openstreetmap.org/wiki/Contributors#Australia.
> >> Or is any url from the web of an image ok to be pasted without any
> further consideration other than relevance?
> >> Nev
> >>
> >>
> >>
> >> ___
> >> Talk-au mailing list
> >> Talk-au@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-au
> >>
> >> _
> >> This mail has been virus scanned by Australia On Line
> >> see http://www.australiaonline.net.au/mailscanning
> >>
> >
> >
> >
> >
>
>
>
>
> --
>
> 

[Talk-it] Conca/postazione difensiva militare.

[liste DOT girarsi AT posteo DOT eu]

Questa conca [0], forse scavata o naturale a fianco un masso, era usata 
per postazione difensiva (mia supposizione visto quanto lì vicino), lì 
vicino a pochi metri ci sono anche dei sentieri/trincee, o tali, 
comunque dei passaggi a lato del dosso della montagna/colle.


Come taggare questa che fu una postazione?

E soprattutto come si mappano le conche?

Sarà larga 2,5 metri in tutto e profonda 70 cm circa

forse:

disused:military=defensive_dell



[0] https://imgur.com/hOsMw6l



--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [OSM-talk] [Osmf-talk] ODbL text

[James]

Just because you are not the curator of the license doesnt mean you cant
display the full legal text somewhere else...The text wont change. GPL,
LGPL, BSD, etc projects usually distribute their software with a license
text file with the full legal text and dont depend on 1 single point of
failure

On Sun, Apr 8, 2018, 8:13 AM Simon Poole,  wrote:

>
>
> Am 08.04.2018 um 13:30 schrieb James:
>
> why not host it on the osmf website?
>
>
> Because we don't own the domain (which is what most references to the
> actual text use) and are not the curators of the licence (aka we could in
> principle simply covertly change the text of the license, having a third
> party publish the text is in principle a good idea for such reasons).
>
> Simon
>
> PS: that doesn't mean that having our own clean copy as a backup wouldn't
> be a good idea, but IMHO the pointer to archive.org is probably the best
> of all bad solutions right now.
>
>
> On Sun, Apr 8, 2018, 5:46 AM Simon Poole,  wrote:
>
>> Currently I'm pointing to
>> http://web.archive.org/web/20180317184051/https://opendatacommons.org/licenses/odbl/
>> however as the opendatacommons.org links are all over the place that
>> isn't really a solution. OKI seems to be aware of the issue, but that is
>> about all what we know (they seem to be intending to move the site to a
>> static website, but there doesn't seem to be a time line or anything
>> available that would indicate if that will happen soon or in a decade).
>>
>> I'm sure waving some $ bills in the direction of OKI/Viderum would get it
>> fixed pronto, but it is obviously an undesirable situation that we are
>> depending on a third party that doesn't seem to be interested to provide a
>> stable link to our licence terms.
>>
>> Simon
>>
>> Am 04.04.2018 um 11:27 schrieb Martin Koppenhoefer:
>>
>>
>>
>> 2018-04-04 10:23 GMT+02:00 Javier Sánchez Portero :
>>
>>> Hello
>>>
>>> My name is Javier Sánchez, from Spain.
>>>
>>> The link to the ODbL 1.0 License [1] is not available since January.
>>> This is an annoyance if trying to ask for explicit permission to any data
>>> source. Is there any alternative reference? Should not be fine that OSMF
>>> provide a copy of the text in their site while opendatacommons.org is
>>> down?
>>>
>>> [1] https://opendatacommons.org/licenses/odbl/1.0/
>>>
>>> Regards, Javier
>>>
>>
>>
>>
>> I agree we should host our own copy of the license.
>>
>> If you need the license text urgently, you can find it here in the
>> Internet Archive (not a general solution obviously):
>>
>> https://web.archive.org/web/20180316015654/https://opendatacommons.org/licenses/odbl/1.0/
>>
>> This is a snapshot from yesterday, so somehow they got through, but I
>> confirm I didn't ge the page either, Error 522.
>>
>> Cheers,
>> Martin
>>
>>
>> ___
>> osmf-talk mailing 
>> listosmf-talk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/osmf-talk
>>
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Osmf-talk] ODbL text

[Simon Poole]

Am 08.04.2018 um 13:30 schrieb James:
> why not host it on the osmf website?

Because we don't own the domain (which is what most references to the
actual text use) and are not the curators of the licence (aka we could
in principle simply covertly change the text of the license, having a
third party publish the text is in principle a good idea for such reasons).
 
Simon

PS: that doesn't mean that having our own clean copy as a backup
wouldn't be a good idea, but IMHO the pointer to archive.org is probably
the best of all bad solutions right now.
>
> On Sun, Apr 8, 2018, 5:46 AM Simon Poole,  > wrote:
>
> Currently I'm pointing to
> 
> http://web.archive.org/web/20180317184051/https://opendatacommons.org/licenses/odbl/
> however as the opendatacommons.org 
> links are all over the place that isn't really a solution. OKI
> seems to be aware of the issue, but that is about all what we know
> (they seem to be intending to move the site to a static website,
> but there doesn't seem to be a time line or anything available
> that would indicate if that will happen soon or in a decade).
>
> I'm sure waving some $ bills in the direction of OKI/Viderum would
> get it fixed pronto, but it is obviously an undesirable situation
> that we are depending on a third party that doesn't seem to be
> interested to provide a stable link to our licence terms.
>
> Simon
>
>
> Am 04.04.2018 um 11:27 schrieb Martin Koppenhoefer:
>>
>>
>> 2018-04-04 10:23 GMT+02:00 Javier Sánchez Portero
>> >:
>>
>> Hello
>>
>> My name is Javier Sánchez, from Spain.
>>
>> The link to the ODbL 1.0 License [1] is not available since
>> January. This is an annoyance if trying to ask for explicit
>> permission to any data source. Is there any alternative
>> reference? Should not be fine that OSMF provide a copy of the
>> text in their site while opendatacommons.org
>>  is down?
>>
>> [1] https://opendatacommons.org/licenses/odbl/1.0/
>>
>> Regards, Javier
>>
>>
>>
>>
>> I agree we should host our own copy of the license.
>>
>> If you need the license text urgently, you can find it here in
>> the Internet Archive (not a general solution obviously):
>> 
>> https://web.archive.org/web/20180316015654/https://opendatacommons.org/licenses/odbl/1.0/
>>
>> This is a snapshot from yesterday, so somehow they got through,
>> but I confirm I didn't ge the page either, Error 522.
>>
>> Cheers,
>> Martin
>>
>>
>> ___
>> osmf-talk mailing list
>> osmf-t...@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/osmf-talk
>
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk
>



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

[talk-au] FOSS4G SotM Oceania update

[John Bryant]

*** UPDATE ***

What: *FOSS4G-SotM Oceania*
When: *20-23 November, 2018*
Where: *University of Melbourne*

Hi all

We're still 226 days away from Day 1, but there is a diligent crew of
people hammering away on pulling this thing together. Things are shaping up
beautifully, this is going to be a fun event!

We've taken on a fortnightly committee meeting cadence, and we last met on
Friday the 6th of April. Please find minutes for this meeting (and all
previous ones) on our wiki page
.

A few key highlights to share:
- dates are now confirmed: 20-23 November 2018
- venue is confirmed: Old Arts Building at the University of Melbourne
- we took a survey of the community on topics of interest, and received 50
responses
- plenty of progress on forging key partnerships, and planning of scheduling,
workshops, and registration

We're aiming to keep communicating via this email list, but we're also very
close to launching our spiffy new website - check back in the next week or
so at http://foss4g-oceania.org for event updates & information. For those
interested in following the planning process as it unfolds, we're posting
minutes on the wiki , and
working planning documents in our Google Drive folder

.

Heading to Locate in Adelaide this week? Some of our committee members will
be there... keep an eye out for Alex Leith, Greg Lauer, Kristy Van Putten,
Trisha Moriarty, and Adam Steer. Find Alex at GeoRabble and ask him for a
FOSS4G-SotM Oceania sticker for your laptop! (but please save one for me)

We want to hear from you! Get in touch with us:

Email: ad...@foss4g-oceania.org

Twitter: @FOSS4G_Oceania 


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

Re: [OSM-talk] [Osmf-talk] ODbL text

[James]

why not host it on the osmf website?

On Sun, Apr 8, 2018, 5:46 AM Simon Poole,  wrote:

> Currently I'm pointing to
> http://web.archive.org/web/20180317184051/https://opendatacommons.org/licenses/odbl/
> however as the opendatacommons.org links are all over the place that
> isn't really a solution. OKI seems to be aware of the issue, but that is
> about all what we know (they seem to be intending to move the site to a
> static website, but there doesn't seem to be a time line or anything
> available that would indicate if that will happen soon or in a decade).
>
> I'm sure waving some $ bills in the direction of OKI/Viderum would get it
> fixed pronto, but it is obviously an undesirable situation that we are
> depending on a third party that doesn't seem to be interested to provide a
> stable link to our licence terms.
>
> Simon
>
> Am 04.04.2018 um 11:27 schrieb Martin Koppenhoefer:
>
>
>
> 2018-04-04 10:23 GMT+02:00 Javier Sánchez Portero :
>
>> Hello
>>
>> My name is Javier Sánchez, from Spain.
>>
>> The link to the ODbL 1.0 License [1] is not available since January. This
>> is an annoyance if trying to ask for explicit permission to any data
>> source. Is there any alternative reference? Should not be fine that OSMF
>> provide a copy of the text in their site while opendatacommons.org is
>> down?
>>
>> [1] https://opendatacommons.org/licenses/odbl/1.0/
>>
>> Regards, Javier
>>
>
>
>
> I agree we should host our own copy of the license.
>
> If you need the license text urgently, you can find it here in the
> Internet Archive (not a general solution obviously):
>
> https://web.archive.org/web/20180316015654/https://opendatacommons.org/licenses/odbl/1.0/
>
> This is a snapshot from yesterday, so somehow they got through, but I
> confirm I didn't ge the page either, Error 522.
>
> Cheers,
> Martin
>
>
> ___
> osmf-talk mailing 
> listosmf-talk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/osmf-talk
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-ja] 高速道路の定義について

[tomoya muramoto]

みなさま

ご意見ありがとうございます。
とりまとめしておきながら何ですが、道路関係はあまり詳しくないので、用語等の間違いがあったらガンガン指摘していただけると助かります。

To Ras and Roadさん

少し追加でご意見をお伺いさせてください。
「高速道路ナンバリング」については、国交省のページに一覧や路線図が掲載されているので確認可能だろうと思っています。(法で規定されている情報なので著作性はないと判断しています)
http://www.mlit.go.jp/road/sign/numbering/index.html
いっぽう「高規格幹線道路」については、Ras and
Roadさんが提示されたようにいくつかの種類があるようですが、それぞれの該当道路一覧を確認する方法はございますか？少し調べたのですがwikipedia情報しかわかりませんでした。
なお類似した「地域高規格道路」については、注記しておけばある程度は混乱を防げるので、問題ないと思います。

To hayashiさん
「歩行者、軽車両通行止め」と「access=no、motor_vehicle=yes」にはどのような差異がございますでしょうか？私は両者は同じものと認識しておりました。もう少し言えば、hayashi様の提案2を協議する中で、「日本においてmotor_vehicleは何に該当するのか」が明確にされるものと認識しておりました。

4/8改定
-
*提案1 日本のmotorwayの定義をJapan taggingに記載された内容から変更する。
*提案1-1 日本のmotorwayの定義を、(1) 高速道路ナンバリングされた道路(高規格幹線道路を含む)、(2) 都市高速道路 または
東京高速道路とする。(muramoto?)
*提案1-2 日本のmotorwayの定義を、(1) 高規格幹線道路、(2) 都市高速道路 または 東京高速道路とする。(Ras and Road)

*提案2 accessタグの車両種別について日本での定義を取り決める(hayashi)

*提案3-1 motorroad=yesの定義を「自動車専用道路」標識がついた道路とする(muramoto)
(補足：提案3-1を採用した場合、提案1-1または1-2の定義から外れたmotorwayは、trunk/primary +motorroad=yes
に置き換えることになる)
*提案3-2 motorroad=yesの定義を「歩行者、自転車通行止め」の道路とする(zyxzyx,
https://forum.openstreetmap.org/viewtopic.php?pid=690508)
*提案3-3 motorroad=yesの定義を「歩行者、軽車両通行止め」の道路とする(提案3-2の派生)
*提案3-4 motorroad=yesの定義を「access=no、motor_vehicle=yes」とする(hayashi)

*提案4 道路運送法に基づく自動車道（アネスト岩田ターンパイクなど）は日本のmotorwayに含めない。(Ras and Road)

*提案5 道路運送法に基づく自動車道には、県道路公社の管理であっても県道ではない道路がある。これはtertiaryとする。(Ras and Road)
-
サブ番号を付けた提案は、どれか一つを選ぶ形式で賛否をとろうと思っています。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[talk-au] Virtual Mapping Party for Brisbane

[Joel H.]

Hello everyone!

With the next Brisbane mapping party dawning on us very shortly, I
though it would be a great opportunity to get community involvement in
remote mapping the buildings from satellite!

The area will be around Indooroopilly, Taringa and St Lucia, Since that
will probably be where our next event is.

I will colour-code loose zones for people to map in (similar rules to
HOTOSM, try to stay in your zone).


So please, if you are interested please respond ASAP!


-- Joel H.



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

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[mmd]

Am 05.04.2018 um 11:38 schrieb Florian Lohoff:

> On Wed, Apr 04, 2018 at 07:54:30PM +0200, Michael Reichert wrote:

>> Ich bin sehr daran interessiert, die Abstimmung mit den Füßen
>> auszuwerten, und würde mich freuen, wenn du deinen Code entweder mir zur
>> Verfügung stellen könntest oder gleich als freie Software
>> veröffentlichen könntest. Die Auswertung ist nicht ganz einfach, weil
>> man weder einfach die Objekte noch die Länge noch den Flächeninhalt
>> zählen muss, sondern auch beachten muss, wer was beigetragen hat.

> Was ich mache ist das ich mir für jeden node merke welche Wege attached
> sind. Dann gehe ich alle Wege durch (Nur die lines - also high und
> waterway) und gucke ob an 2 aufeinanderfolgenden nodes jeweils eine
> area mit derselben ID attached ist.

Netter Testfall. Ich habe mal versucht, das ganze soweit möglich mit
Turbo nachzustellen, allerdings mit der vereinfachten Annahme, dass ein
highway=* und landuse=* Way mindestens 2 gemeinsame Knoten haben müssen.
Das mit dem aufeinander folgend lässt sich leider nicht so recht abbilden.

Den Link zur Query habe ich auf folgende Github-Seite ausgelagert, weil
sich in diesem Medium nachträglich kein Post mehr ändern lässt.

https://github.com/drolbr/Overpass-API/issues/467#issuecomment-379536822

-- 





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

Re: [OSM-ja] 高速道路の定義について

[yuu hayashi]

hayashiです

-
*提案1 日本のmotorwayの定義をJapan taggingに記載された内容から変更する。
*提案1-1 日本のmotorwayの定義を、(1) 高速道路ナンバリングされた道路(高規格幹線道路を含む)、(2) 都市高速道路 または
東京高速道路とする。(muramoto?)
*提案1-2 日本のmotorwayの定義を、(1) 高規格幹線道路、(2) 都市高速道路 または 東京高速道路とする。(Ras and Road)

*提案2 accessタグの車両種別について日本での定義を取り決める(hayashi)

*提案3-1 motorroad=yesの定義を「自動車専用道路」標識がついた道路とする(muramoto)
(補足：提案3-1を採用した場合、提案1-1または1-2の定義から外れたmotorwayは、trunk/primary +motorroad=yes
に置き換えることになる)
*提案3-2 motorroad=yesの定義を「自転車進入不可」の道路とする(zyxzyx,
https://forum.openstreetmap.org/viewtopic.php?pid=690508)
*提案3-2-(a) motorroad=yesの定義を「歩行者、自転車通行止め」の道路とする(Ras and Road)
*提案3-2-(b) motorroad=yesの定義を「歩行者、軽車両通行止め」の道路とする(Ras and Road)
*提案3-2-(c) motorroad=yesの定義を「access=no、motor_vehicle=yes」とする(hayashi)

*提案4 道路運送法に基づく自動車道（アネスト岩田ターンパイクなど）は日本のmotorwayに含めない。(Ras and Road)

*提案5 道路運送法に基づく自動車道には、県道路公社の管理であっても県道ではない道路がある。これはtertiaryとする。(Ras and Road)
-
Ras and Road さんの分を追記しました。



私はこのスレッドではハブられものなので,
私が進行役をやってても 誰の承認もなく勝手にやってる感が強くなるので まとまるものもまとまらなくなるのではないかと危惧していました。

muramotoさん進行役よろしくお願いいたします。


2018年4月8日 12:43 Ras and Road :

> Ras and Roadです。
>
> muramotoさん、取り纏めありがとうございます。
> 提案1-1と提案1-2を分けて賛否を聞くことがよいと思います。
> それぞれの考慮点はこれまでの投稿で述べてきましたが、あらためて整理します。どちらがhighway=motorwayとして適しているか、
> みなさんの感覚やご意見を聞きたいですね。
>
> 【提案1-1】 日本のmotorwayの定義を、(1) 高速道路ナンバリングされた道路(高規格幹線道路を含む)、(2) 都市高速道路 または
> 東京高速道路とする。
> この案では、京葉道路・西湘バイパス・小田原厚木道路・長崎バイパス等、高規格幹線道路ではない「一般有料道路」が含まれます。その一方、判断基準は「
> 高速道路ナンバリングされているか」「都市高速か」だけなので、現地や机上での確認が容易です。
> 多少の例外を許容しつつ、わかりやすさに重点を置いた定義と言えます。
>
> 【提案1-2】 日本のmotorwayの定義を、(1) 高規格幹線道路、(2) 都市高速道路 または 東京高速道路とする。
> 高規格幹線道路とは、「『四全総』(昭和62年6月30日閣議決定)及び『２１世紀の国土のグランドデザイン』(平成10年3月31日閣議決定)
> で国土の骨格となる基幹的な高速陸上交通網を形成するものとして構想」（カギカッコ内は国交省道路局「道路行政の簡単解説」から引用）されたものですが、
> 広く周知されているとは言えない用語であり、また、類似した名称「地域高規格道路」があるために、提案1-1に比べて混乱のおそれがあります。
> 具体的には「日本の高速道路一覧」(Wikipedia)の、「国土開発幹線自動車道」「高速自動車国道」「高規格幹線道路（第四次全国総合開発計画）」「
> 高速自動車国道に並行する一般国道自動車専用道路」「国土交通大臣指定に基づく高規格幹線道路（一般国道の自動車専用道路）」「
> 本州四国連絡道路に掲げられる道路」が該当します。これに都市高速道路と東京高速道路を加えたものがこの案です。
> OSMのhighway=motorwayの概念により近いと考えます。
>
> また、提案3-2について補正案です。
> 「自転車進入不可」は感覚的には理解できるのですが、zyxzyxさんが掲げられた標識は「自転車通行止め」なので用語が正しくないと思います。
> *提案3-2-(a) motorroad=yesの定義を「歩行者、自転車通行止め」の道路とする
> *提案3-2-(b) motorroad=yesの定義を「歩行者、軽車両通行止め」の道路とする
> のいずれかとしてはいかがでしょうか。
> 些末ながら、(a)の提案は自転車の通行が規制されていれば大八車が通行可能であってもmotorroad=yesということになります。（
> 具体例：国道6号四つ木陸橋
> https://goo.gl/maps/qHV59CfAvY32 ）
>
>
> ** Ras and Road **
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] BANO : aide pour légende

[Christian Quest]

Le 8 avril 2018 à 11:05, deuzeffe  a écrit :

> Vu ! Mais j'ai quand même l'impression qu'on perd des alertes :(
>
>
En principe les alertes pertinentes sont bien là... sauf erreur.



> Autre question :
>
> - « légende des points turquoise = voies sans adresses numérotées » si
> j'ai bien suivi, puisque j'en retrouve dans cette catégorie dans
> cadastre/fantoir ;
>
> - Or, sur le terrain (et même sur la couche BANO), ces voies sont bien
> numérotée (numéro gris <- BAN) ;
>
> - Donc, ma question, de quelle base et avec quel code/flag/tag provient
> l'info. « voie non numérotée » ?
>
>

Ces points turquoise indiquent les voies pour lesquelles on n'a pas trouvé
de numéro dans BANO mais qu'on a bien la voie dans OSM (d'où la
localisation de ce point).
Cela ne veut pas dire qu'il n'y en a pas sur le terrain ni dans la BAN
(gris).

C'est potentiellement un indicateur de nombreux numéros manquants... donc
intéressant de la ajouter dans OSM.

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

Re: [OSM-talk] [Osmf-talk] ODbL text

[Simon Poole]

Currently I'm pointing to
http://web.archive.org/web/20180317184051/https://opendatacommons.org/licenses/odbl/
however as the opendatacommons.org links are all over the place that
isn't really a solution. OKI seems to be aware of the issue, but that is
about all what we know (they seem to be intending to move the site to a
static website, but there doesn't seem to be a time line or anything
available that would indicate if that will happen soon or in a decade).

I'm sure waving some $ bills in the direction of OKI/Viderum would get
it fixed pronto, but it is obviously an undesirable situation that we
are depending on a third party that doesn't seem to be interested to
provide a stable link to our licence terms.

Simon


Am 04.04.2018 um 11:27 schrieb Martin Koppenhoefer:
>
>
> 2018-04-04 10:23 GMT+02:00 Javier Sánchez Portero
> >:
>
> Hello
>
> My name is Javier Sánchez, from Spain.
>
> The link to the ODbL 1.0 License [1] is not available since
> January. This is an annoyance if trying to ask for explicit
> permission to any data source. Is there any alternative reference?
> Should not be fine that OSMF provide a copy of the text in their
> site while opendatacommons.org  is down?
>
> [1] https://opendatacommons.org/licenses/odbl/1.0/
> 
>
> Regards, Javier
>
>
>
>
> I agree we should host our own copy of the license.
>
> If you need the license text urgently, you can find it here in the
> Internet Archive (not a general solution obviously):
> https://web.archive.org/web/20180316015654/https://opendatacommons.org/licenses/odbl/1.0/
>
> This is a snapshot from yesterday, so somehow they got through, but I
> confirm I didn't ge the page either, Error 522.
>
> Cheers,
> Martin
>
>
> ___
> osmf-talk mailing list
> osmf-t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk



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

Re: [OSM-talk-fr] BANO : aide pour légende

[deuzeffe]

Vu ! Mais j'ai quand même l'impression qu'on perd des alertes :(

Autre question :

- « légende des points turquoise = voies sans adresses numérotées » si 
j'ai bien suivi, puisque j'en retrouve dans cette catégorie dans 
cadastre/fantoir ;


- Or, sur le terrain (et même sur la couche BANO), ces voies sont bien 
numérotée (numéro gris <- BAN) ;


- Donc, ma question, de quelle base et avec quel code/flag/tag provient 
l'info. « voie non numérotée » ?


--
deuzeffe

Le 08/04/2018 à 09:40, Christian Quest a écrit :
J'ai finalement quand même modifié la requête afin de ne pas signaler 
les voies pour lesquelles un nom similaire est trouvé entre BANO et BAN, 
mais pour lesquelles le rapprochement FANTOIR n'a pas été fait côté BAN.


Moins de gris pointillé et de rouge pointillé du coup, ce qui allège pas 
mal de rendu par endroit comme dans l'exemple de deuzeffe...


Le 7 avril 2018 à 22:48, Christian Quest > a écrit :


Il y a sûrement des cas où ces signalements sont utile, comme tu
l'indiques sur des adresses toutes fraiches. Donc je laisse, mais il
va falloir compléter le wiki ;)

Il n'est pas toujours évident en effet d'être à jour de partout
entre le COG, FANTOIR, les adresses où chacun avance à son rythme.
Le millésimage est un sérieux problème et je pense qu'on n'est pas
top à jour partout côté BANO.

La Poste met à jour vraiment en continu et diffuse chaque mois une
nouvelle version de ses données.
Le cadastre remonte les infos locales une à deux fois par an en
national si j'ai bien compris.
Du coup à la sortie du tuyau on ne peut pas dire que l'un va plus
vit que l'autre.
Pour la BAN en plus, on a l'IGN entre les deux qui jusqu'à présent
attendait les données du cadastre (reçues annuellement) pour
déterminer des positions géographiques aux nouvelles adresses reçues
de La Poste (sans info géo).


Le 7 avril 2018 à 19:51, Christian Rogel
> a écrit :



> Le 7 avr. 2018 à 19:38, Christian Quest > a écrit :
>
> Ces tracés pointillés gris ne sont pas pertinents... ils indiquent 
les adresses de la BAN pour lesquelles un code FANTOIR de voie n'a pas été 
retrouvé.
>
> Je vais les retirer du rendu car ils ne sont pas utiles pour les 
contributions OSM et BANO, je ne sais même plus pourquoi je les avais ajouté... du 
debug qui est resté ;)

Pourtant, ils permettent quelquefois de voir les retards du
cdastre par rapport aux décisions nouvelles des communes,
généralements dans les zones les plus rurales.
Je soupçonnais que la Poste pouvait doubler le cadastre. Qu’en
est-il ?


Christian R.


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





-- 
Christian Quest - OpenStreetMap France





--
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

[Talk-cz] Dubnový Missing Maps mapathon v Praze - v Seznam.cz

[Pavel PETR]

Dobrý den,

zveme Vás na dubnový pražský mapathon Missing Maps s Lékaři bez hranic,
který proběhne v úterý 24. 4. od 18:00 v sídle společnosti Seznam.cz, na
adrese Radlická 10, Praha 5. Počet míst je omezený, bezplatná registrace
zde:
https://www.eventbrite.co.uk/e/dubnovy-missing-maps-mapathon-v-praze-v-seznamcz-registration-44870353435

Za komunitu pořadatelů
-- 
Pavel PETR
3D scanning technician
tweeting @pointcloudfever 
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] BANO : aide pour légende

[Philippe Verdy]

A ce sujet, la mise à jour du suivi par commune ne se termine pas et
affiche une erreur "problème de mise à jour" au bout de quelques secondes.
Exemple:
http://cadastre.openstreetmap.fr/fantoir/#insee=79298=0


Le 8 avril 2018 à 09:40, Christian Quest  a écrit :

> J'ai finalement quand même modifié la requête afin de ne pas signaler les
> voies pour lesquelles un nom similaire est trouvé entre BANO et BAN, mais
> pour lesquelles le rapprochement FANTOIR n'a pas été fait côté BAN.
>
> Moins de gris pointillé et de rouge pointillé du coup, ce qui allège pas
> mal de rendu par endroit comme dans l'exemple de deuzeffe...
>
> Le 7 avril 2018 à 22:48, Christian Quest  a
> écrit :
>
>> Il y a sûrement des cas où ces signalements sont utile, comme tu
>> l'indiques sur des adresses toutes fraiches. Donc je laisse, mais il va
>> falloir compléter le wiki ;)
>>
>> Il n'est pas toujours évident en effet d'être à jour de partout entre le
>> COG, FANTOIR, les adresses où chacun avance à son rythme. Le millésimage
>> est un sérieux problème et je pense qu'on n'est pas top à jour partout côté
>> BANO.
>>
>> La Poste met à jour vraiment en continu et diffuse chaque mois une
>> nouvelle version de ses données.
>> Le cadastre remonte les infos locales une à deux fois par an en national
>> si j'ai bien compris.
>> Du coup à la sortie du tuyau on ne peut pas dire que l'un va plus vit que
>> l'autre.
>> Pour la BAN en plus, on a l'IGN entre les deux qui jusqu'à présent
>> attendait les données du cadastre (reçues annuellement) pour déterminer des
>> positions géographiques aux nouvelles adresses reçues de La Poste (sans
>> info géo).
>>
>>
>> Le 7 avril 2018 à 19:51, Christian Rogel > .fr> a écrit :
>>
>>>
>>>
>>> > Le 7 avr. 2018 à 19:38, Christian Quest  a
>>> écrit :
>>> >
>>> > Ces tracés pointillés gris ne sont pas pertinents... ils indiquent les
>>> adresses de la BAN pour lesquelles un code FANTOIR de voie n'a pas été
>>> retrouvé.
>>> >
>>> > Je vais les retirer du rendu car ils ne sont pas utiles pour les
>>> contributions OSM et BANO, je ne sais même plus pourquoi je les avais
>>> ajouté... du debug qui est resté ;)
>>>
>>> Pourtant, ils permettent quelquefois de voir les retards du cdastre par
>>> rapport aux décisions nouvelles des communes, généralements dans les zones
>>> les plus rurales.
>>> Je soupçonnais que la Poste pouvait doubler le cadastre. Qu’en est-il ?
>>>
>>>
>>> Christian R.
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>
>
>
> --
> 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] Flächen/Wege // Trolling in changesets

[Florian Lohoff]

Hola,

On Sun, Apr 08, 2018 at 02:57:34AM +0200, "Christian Müller" wrote:
> > Gesendet: Sonntag, 08. April 2018 um 00:43 Uhr
> > Von: "Florian Lohoff" 
> > An: "Christian Müller" 
> > Cc: talk-de@openstreetmap.org
> > Betreff: Re: [Talk-de] Flächen/Wege // Trolling in changesets
> >
> > Ich habe mehrfach das Gegenteil behauptet und dafür auch klare
> > Grundlagen genannt - Ich sehe einfach nicht den Vorteil für eine 
> > Minderheit (Nachweis siehe vorangegangene Mail) die kein "Nichts" in der
> > Karte sehen will, allen Flächen absichtlich Fehler
> > Geographischer und Topologischer Natur hinzuzufügen und es dazu für
> > Neumapper nahezu unmöglich zu machen korrekte Daten zu erfassen.
> 
> Irgendwie liest du auch nur das, was du lesen willst, oder?  Da
> brauchst du dich dann auch nicht wundern, wenn niemand die von dir
> verschickten Dokus liest.  Wenn das width-tag fehlt, wird je nach
> Straßenklasse und evtl. dem lanes-Attribut eine Breite errechnet.

Nur und ausschliesslich im Renderer und das auch nur Renderer Spezifisch
und das auch in Pixeln je nach Auflösung - Mit der realen Breite hat und
hatte das nie zu tun.

Du scheinst aber hier dem Trugschluss aufzusitzen das OSM eine Karte
ist. Das ist es nicht OSM ist und war nie eine Karte. 

OSM ist eine Sammlung von Geografischen Fakten. Die mit Mapnik erzeugte
Karte ist nur ein Beispiel diese Sammlung an Fakten zu visualisieren.

> Das eine genaue Angabe oft fehlt, ist ein Missstand, rechtfertigt
> aber nicht die Annahme, dass wir nur die Mittellinie von Straßen
> erfassen.  Das geographische Objekt, dass von einem mit highway=*

"Nur" habe ich nie behauptet - Du hast behauptet das wir die Mittellinie
nicht erfassen sondern ein Objekt mit Breite - Bei einem 1 Dimensionalen
Objekt ist diese Annahme - aehm - schwer nachzuvollziehen. Das stimmt so
einfach nicht. Wenn wir die Straße mit einer korrekten Breite erfassen
dann gibt es für den Straßenabschnitt 2 Objekte. Die Mittellinie als
geometrische Mitte der Straße mit allen Attributen wie
Geschwindigkeitsbeschränkung etc und eine Objekt mit der Ausdehnung -
Eine Highway Area.

> getaggten Datenbankobjekt repräsentiert wird, ist eine Straße,
> mit Straßenfläche und ggf. weiteren Eigenschaften, nicht diese
> Mittellinie.  Wir erfassen die Straße als Mittellinie, nicht umge-

Wir nennen es Straße - Geometrisch ist es die Mittellinie - und wir
erfassen viel - Aber die Breite eben nur auf einem verschwindend
geringen teil der Wege. 

> kehrt.  Nach deiner Argumentation müssten ja die Seitenstreifen,
> Trennlinien, Standstreifen nochmals als Idealisierung in den Daten-
> bestand, weil die Mittellinie nur für sich steht, steht sie aber
> nicht.  Es wurde sowohl im Wiki als auch in der Mailingliste
> mehrmals darauf hingewiesen, dass Spuren und Standstreifen /nicht/
> separat erfasst werden, /weil/ die Mittellinie die baulich nicht
> getrennte Straßen/fläche/ repräsentiert.

Korrekt - Die Mitellinie ist die Geometrische Mitte der Straße - Und die
erfassen wir. Dazu noch attribute der Straße - Mehr nicht.  

> Ich verstehe auch nicht, wieso du dich von einer Erklärung zur Situation
> der Bestandsdaten angegriffen fühlst.  Ich habe auch nie behauptet, dass
> ich irgendeinen Fehler hinzufügen will, in der Art, wie du ihn beschreibst.
> Es ging darum aufzuzeigen /warum/ diese Daten so in der DB zu finden sind,
> wie sie es sind.

Umgekehrt wird ein Schuh draus - Du versuchst mir in der ich weiss nicht
wievielten Mail zu sagen das wir bei Straßen ja eine Breite erfassen und
das es schon okay ist Flächen damit zu verbinden weil man das ja "einfach raus
rechnen kann". Und das ist halt in meinen Augen an so vielen Stellen 
falsch das ich manchmal echt Baff bin. 

Ein 1 Dimensionales Objekt kann nie eine reale Breite haben. Die wird an
den Stellen wo die Straße angezeigt wird nur dazu geschummelt. Mit Real
erfasster Breite hat und hatte das nie zu tun und wird es auch nie zu
tun haben. Wenn du eine Reale Fläche/Breite haben willst musst du das
als Fläche separat erfassen.

> Vielleicht war das ja bei dir schon immer so, dass du mit 2cm genauen Luft-
> bildern gemappt hast.  Ich hingegen kenne OSM noch aus einer Zeit, wo für
> das hiesige Gebiet keine sonderlich gute Auflösung mit den Quellen zur Ver-
> fügung stand, die zur Nutzung mit OSM erlaubt waren.

Ich komme aus NRW und ja - wir hatten früh und lange Zugriff auf 40cm
Luftbilder - Erst über das LVermA jetzt über ESRI. 

Und ich kenne OSM noch aus Zeiten da ich mit einem Feldbuchrahmen
rum gerannt bin und zu meinen GPS Tracks noch Zeichnungen gemacht habe.

Hat aber auch alles nichts mit der Genauigkeit zu tun. Auch damals habe
ich nicht einfach gedankenverloren Flächen an Wege geklebt weil das bei
egal welcher Genauigkeit einfach topologisch falsch ist und bleibt.

> > Man kann das eben genau nicht raus rechnen oder "Mal eben Algorithmisch
> > Lösen" - Diesen Beweis sind bisher alle die das behauptet haben schuldig
> > geblieben.
> 
> 

Re: [Talk-de] Flächen/Wege // Trolling in changesets

[Falk Zscheile]

Ich möchte das ganze im Folgenden versuchen ein wenig auf eine
Meta-Ebene zu heben, möchte aber nicht verhelen, dass ich auf
highway=value geklebte landuse=value nicht mag bzw. ablehnend
gegenüber stehe. Aber auch ich habe mal als "Verkleber" angefangen:

Abgesehen von der Sinnhaftigkeit (keine Metaebene) gibt es auf der
Metaebene folgende Aspekte:

1. Durch die snap-Funktion im JOSM lassen landuse und highway viel
leichter verbinden, als wieder trennen. Dadurch haben die
"Verschmelzer" beim Mappen einen taktischen und zeitlichen Vorteil
gegenüber den "Trennern".

2. Das getrennte erfassen erfordert mehr Genauigkeit. Man muss viel
weiter hineinzoomen, um Flächen zu erfassen, damit man nicht selbst
"Opfer" der snap-Funktion von JOSM wird. Man hat also einen kleineren
Kartenausschnitt auf dem Bildschirm. Hierdurch benötigt man mehr Zeit
und muss trotzdem aufpassen (wegen der snap-Funktion). Auch Mapper
sind sind nur Menschen, also bequem und möchten trotzdem viel pro
Zeiteinheit schaffen. Auch das ist ein strategischer Nachteil der
getrennten Erfassung. Die Verschmelzer sind faktisch im Vorteil, weil
sie mehr pro Zeiteinheit Mappen können. Dann können sie ggf. auch noch
sagen, "Seht her, in den Daten ist viel mehr verklebt als getrennt!
Wir sind die Mehrheit, wir haben Recht!"

3. Durch das verschmelzen sieht die Datenbasis im JOSM auch besser --
weil aufgeräumter wirkend -- aus, als mehrere parallele Linien. Man
sollte diesen ästhetischen Aspekt nicht vernachlässigen. Wir sind ein
Projekt, das von Laien getragen wird. Da spielen solche Aspekte eine
viel größere Rolle, als in einem professionellen Umfeld mit
festgefügten Regeln und Normen (wir müssen Regeln und Normen erst
finden und ständig darüber diskutieren).

4. Menschliches Beharrungsvermögen: Niemand gibt gern Gewohnheiten
auf. Warum sollte also ein "Verschmelzer" sich ändern? Zumal der
Verschmelzer merkt, dass die andere Methode aufwendiger ist und mehr
Sorgfalt erfordert. (Vielleicht liegt die Sorgfalt auch nicht so in
seiner Natur, wogegen die "Trenner" eher von pingeliger Natur sind).

5. Eine eigene Ausprägung von Beharrungsvermögen ist: Die Arbeit des
"Verschmelzers", das Verschmelzen, wird ein Stück weit entwertet, wenn
jetzt immer getrennt werden soll. Niemand sieht seine Arbeit gern
entwertet und wird daher immer alles versuchen, diese zu erhalten und
gegen Änderungen zu verteidigen.

6. Eine weitere Ausprägung des Beharrungsvermögens findet sich auch
bei der Regeldiskussion "das ist so nicht/anders Dokumentiert".
Einerseits sind Regeln sehr wichtig, weil erst sie eine Basis geben,
auf der man gemeinsam arbeiten kann. Andererseits ändern sich die
Gegebenheiten, auf denen die Regeln basieren. Vor fünf Jahren war man
froh ein einigermaßen vollständiges Straßennetz (DE) zu haben. Da
wollte man nicht über Straßenflächen diskutieren und gab sich
entsprechende Regeln. Doch warum sollen die Regeln heute noch gelten?
Die Regeln bei OSM sind ja nicht die (universell gültigen)
Menschenrechte. Also: geänderte Situation, geänderte Regeln. Das
Problem: Man erkennt quasi immer nur in der Retrospektive, ob sich die
Situation tatsächlich geändert hat. Da also niemand aus der Zukunft
zurückblicken kann, entstehen solche langen Threads zwischen
"Verklebern" und "Trennern".

Daraus folgt für mich auf der Handlungsebene:

Bei den Punkten 1. bis 3. muss auf Ebene der Werkzeuge zunächst
Waffengleichheit zwischen Verklebern und Trennern hergestellt werden!

Bei den Punkten 1. bis 3. wünsche ich mir einfach einen mutigen
Entwickler, der eine Warnung einbaut, wenn landuse als Fläche und
highway als way miteinander verbunden werden sollen. Problem: Wir
zeichnen erst die Geometrie und geben dann die Eigenschaften/Tags.
Aufgrund meiner Grundauffassung sollte das überhaupt nicht möglich
sein bzw. um den Verschmelzern nicht auf die Füße zu treten nur als
"opt in". Dann wäre zumindest was die Schwierigkeit angeht
einigermaßen Waffengleichheit hergestellt und neue Mapper kommen nicht
mehr so leicht in Versuchung zum "Verkleber" zu werden.

Eine schöne Lösung wäre es auch, wenn die snap-Funktion bei highways
nicht funktionieren würde (zumindest nicht für ways, die noch keine
Tags haben und generell nicht für landuse auf highway).

Wichtig ist, dass man das snap-Verhalten von landuse auf highway (way)
in der Grundfunktion abstellt, damit die Leute gar nicht erst
"klebstoffsüchtig" [Entschuldigung für den Kalauer] werden. Dann
stellen sich die Probleme aus Nr. 4 bis 6 nicht in gleichem Maße. Dann
erledigt sich das Problem in einem gewissen Maß von selbst. "Es wächst
sich raus."

Eine andere Möglichkeit ist es endlich handliche Tools zu entwickeln,
die das Entkleben genauso einfach machen, wie das Verkleben. Das hat
aber die große Gefahr von "edit wars".

An den Punkten 4. bis 6. kann man ansonsten in einem
Freiwilligenprojekt nicht viel ändern, außer vielleicht, das die
Beteiligten selbst Reflektieren, mal was anderes ausprobieren und dann
zu dem Ergebnis kommen "ist ja gar 

Re: [OSM-talk-fr] BANO : aide pour légende

[Christian Quest]

J'ai finalement quand même modifié la requête afin de ne pas signaler les
voies pour lesquelles un nom similaire est trouvé entre BANO et BAN, mais
pour lesquelles le rapprochement FANTOIR n'a pas été fait côté BAN.

Moins de gris pointillé et de rouge pointillé du coup, ce qui allège pas
mal de rendu par endroit comme dans l'exemple de deuzeffe...

Le 7 avril 2018 à 22:48, Christian Quest  a écrit :

> Il y a sûrement des cas où ces signalements sont utile, comme tu
> l'indiques sur des adresses toutes fraiches. Donc je laisse, mais il va
> falloir compléter le wiki ;)
>
> Il n'est pas toujours évident en effet d'être à jour de partout entre le
> COG, FANTOIR, les adresses où chacun avance à son rythme. Le millésimage
> est un sérieux problème et je pense qu'on n'est pas top à jour partout côté
> BANO.
>
> La Poste met à jour vraiment en continu et diffuse chaque mois une
> nouvelle version de ses données.
> Le cadastre remonte les infos locales une à deux fois par an en national
> si j'ai bien compris.
> Du coup à la sortie du tuyau on ne peut pas dire que l'un va plus vit que
> l'autre.
> Pour la BAN en plus, on a l'IGN entre les deux qui jusqu'à présent
> attendait les données du cadastre (reçues annuellement) pour déterminer des
> positions géographiques aux nouvelles adresses reçues de La Poste (sans
> info géo).
>
>
> Le 7 avril 2018 à 19:51, Christian Rogel  > a écrit :
>
>>
>>
>> > Le 7 avr. 2018 à 19:38, Christian Quest  a
>> écrit :
>> >
>> > Ces tracés pointillés gris ne sont pas pertinents... ils indiquent les
>> adresses de la BAN pour lesquelles un code FANTOIR de voie n'a pas été
>> retrouvé.
>> >
>> > Je vais les retirer du rendu car ils ne sont pas utiles pour les
>> contributions OSM et BANO, je ne sais même plus pourquoi je les avais
>> ajouté... du debug qui est resté ;)
>>
>> Pourtant, ils permettent quelquefois de voir les retards du cdastre par
>> rapport aux décisions nouvelles des communes, généralements dans les zones
>> les plus rurales.
>> Je soupçonnais que la Poste pouvait doubler le cadastre. Qu’en est-il ?
>>
>>
>> Christian R.
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Christian Quest - OpenStreetMap France
>



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

Re: [OSM-talk-fr] Import station essence

[Stéphane Péneau]

La communauté allemande vient de donner son avis sur cette proposition 
d'import :

https://lists.openstreetmap.org/pipermail/imports/2018-April/005481.html

En résumé, ils s'opposent à cet import avec des arguments très proches 
des nôtres.


Stéphane

Le 04/04/2018 à 21:34, Stéphane Péneau a écrit :

La réponse est envoyée :
https://lists.openstreetmap.org/pipermail/imports/2018-April/005477.html

Stéphane

Le 04/04/2018 à 10:46, Marc Gemis a écrit :

A lot of fuel stations can be use 24/7 with a bank card
-->
A lot of fuel stations can be used 24/7 with a bank card

___
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