Re: [Talk-at] Meinungen zu Access-Tagging

2020-11-09 Per discussione Wolfgang Schreiter
Sehe das auch wie fkv. access ist überschießend, das Verkehrszeichen lautet ja 
nicht "Betreten verboten ausgenommen...". Man darf auf dieser Straße 
grundsätzlich alles, ausgenommen die bezeichnete Einschränkung, und dafür 
gibt's schon ein elegantes Tagging. Wie Friedrich schon kommentierte, schafft 
access ein Wartungsproblem (z.B. wenn Hoverboards serientauglich werden).

Liebe Grüße
Wolfgang


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


Re: [Talk-at] Gefahr durch Internet-Bergrouten

2020-08-30 Per discussione Wolfgang Schreiter
> -Ursprüngliche Nachricht-
> Von: Marcus MERIGHI 
> Gesendet: Sonntag, 30. August 2020 13:49

> Schau Dir bitte am Krippenstein (Obertraun, OOE) den Weg Richtung
> Heilbronner Kreuz an (nicht die Schotter-Trassen, den alten "Weg"). Dort
> gibt's keinen Weg, weil man direkt am Fels geht. Es gibt aber jede Menge
> Markierungen, weil "offizieller" Wanderweg.
> 
> Soll ich das in OSM jetzt eintragen oder nicht?

Ja, weil markiert, also erkennbar, mit entsprechender Klassifizierung.

> Noch etwas macht es kompliziert: Solange es Bewuchs gibt, gibt es auch
> Trittspuren... nur halt nicht von Menschen. Menschen gehen Gamspfade
> und Gamsen gehen Menschenpfade (sind ja auch nicht bloed :-).

Wenn's schon für Dich nicht klar ist, dann nein. Man kann auf viele Arten auf 
einen Berg gehen, wenn man Extrembergsteiger (oder Gämse) ist. Das begründet 
aber keinen Weg für eine Karte, bestenfalls eine Route für einen Kletterführer. 
Wenn es nicht markiert ist, und auch kein Trampelpfad oder erkennbare 
Steigspuren (von Menschen) da sind (die auch ein konkretes Ziel haben), dann 
existiert es nicht. Wer trotzdem da gehen will, tut es "weglos" (was auch ok 
ist).
 
> Unlaengst im Stodertal: Steig ist etwa 500m lange *nicht* zu sehen (recht
> seltsam und unverstaendlich, weil das Gelaende davor und danach sehr
> aehnlich ist, keine Spuren von Windwurf o.ae.).
> Soll ich jetzt durch einzeichnen einer vernuenftigen Linie die Menschen
> sicher zu den naechsten Trittspuren geleiten oder sollen sie sich das (so wie
> ich), selber suchen?

Würde ich wie in der OEK machen, unterbrochene Wegabschnitte. Das sollte den 
Betrachter schon warnen, dass das kein Spaziergang ist, und entspricht dem was 
sichtbar ist.
 
> > himmelweiter Unterschied, ob ich bei Schwierigkeiten umkehren kann,
> > oder es eine Einbahnstraße ist (z.B. Abklettern in eine Schlucht, aus
> > der man nicht mit gleicher Fähigkeit wieder zurück kommt).
> 
> Schlechtes Beispiel, abklettern ist immer schwieriger als hinauf klettern.

Technisch vielleicht, konditionell eher nicht. Aber umgekehrt funktioniert das 
Beispiel dann 

LG, Wolfgang 


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


Re: [Talk-at] Gefahr durch Internet-Bergrouten

2020-08-30 Per discussione Wolfgang Schreiter
> Von: Stefan Kopetzky 
> Gesendet: Sonntag, 30. August 2020 07:29> 

> Niemand ist davon befreit sich "auf Sicht"
> fortzubewegen, in den Bergen oder sonstwo.

Sehe ich auch so. Wer in der Natur unterwegs ist, auf Wegen oder sonst wo, ist 
dafür verantwortlich, die Gefahren einzuschätzen und sich entsprechend zu 
verhalten. Auch auf ÖK oder Wanderkarten ist nicht 100% Verlass. 

Speziell Nutzern von OSM-basierten Karten muss klar sein (oder gemacht werden), 
dass die Einträge weder aktuell noch richtig sein müssen, und Kartenanbieter 
die Tags ev. nicht auswerten/darstellen.

> Das widerspricht fundamental dem Grundsatz zu Mappen "was ist" aka
> "ground truth". Gemappt werden sollen Wege, die existieren!

Ja, aber ... 
Mapper, die in exponierten Regionen arbeiten, trifft zusätzliche Verantwortung. 
Wenn der "Weg" nur ein paar lokalen Jägern bekannt ist und physisch so gut wie 
nicht existiert, dann gehört er nicht in eine Karte, insbesondere, wenn die 
Begehung noch alpinistische Erfahrung voraussetzt.

Die Problematik entsteht durch den Begriff "Weg" (siehe auch 
https://de.wikipedia.org/wiki/Weg). Im weiteren Sinne ist es eine Verbindung 
(auch ohne physische Entsprechung), im engeren Sinne eine " streifenförmige 
Verbindung", die das Fortkommen erleichtert. 

Beispiel: a) ein Weg (Verbindung) führt über eine Alm - am Boden ist nur Wiese, 
wer den Weg nicht kennt, sieht ihn auch nicht; b) der gleiche Weg, aber 
ausgetreten oder zumindest mit Steigspuren alle paar Meter, sodass ein 
durchschnittlich fähiger Mensch den Zusammenhang erkennt.

Es liegt am Mapper, im Graubereich dazwischen den gesunden Menschenverstand 
einzuschalten, korrekt zu taggen (sac_scale, trail_visibility) und im Zweifel 
nicht zu mappen. Es ist z.B. ein himmelweiter Unterschied, ob ich bei 
Schwierigkeiten umkehren kann, oder es eine Einbahnstraße ist (z.B. Abklettern 
in eine Schlucht, aus der man nicht mit gleicher Fähigkeit wieder zurück 
kommt). trail_visibility schlechter als good und sac_scale größer als 
mountain_hiking sollten immer zum Nachdenken anregen!

LG, Wolfgang




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


Re: [Talk-at] geoimage.at geändert

2020-07-13 Per discussione Wolfgang Schreiter
> Von: Friedrich Volkmann 
> Gesendet: Montag, 13. Juli 2020 14:00


> On 13.07.20 11:34, Wolfgang Schreiter wrote:
> > Der Versatz von geoimage zur basemap beträgt ca. 0.13; -0.44 (JOSM
> Versatz-Einstellungen).
> 
> Was bedeuten diese Zahlen, und wo kommen sie her?

https://josm.openstreetmap.de/wiki/Help/Action/ImageryAdjust

"east and north offset in Mercator coordinates"
Zugänglich in JOSM unter Hintergrund -> Neuer Versatz.

Bzgl. Lagegenauigkeit: ich habe jetzt mal schnell mit Google Maps und NÖ Atlas 
verglichen.  Geoimage stimmt etwas besser überein, ist auch noch geringfügig 
daneben. Aber bei 30 cm und der gegebenen Auflösung ist das schon 
Kaffeesudlesen.



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


Re: [Talk-at] geoimage.at geändert

2020-07-13 Per discussione Wolfgang Schreiter
> Von: Norbert Wenzel 
> Gesendet: Montag, 13. Juli 2020 12:56

> Leider schaff ich's nicht die Liste zu finden im Wiki, könntest du mir bitte 
> den
> Link posten?

Gerne:  https://josm.openstreetmap.de/wiki/Maps

LG
Wolfgang


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


Re: [Talk-at] geoimage.at geändert

2020-07-13 Per discussione Wolfgang Schreiter
> Von: Friedrich Volkmann 
> Gesendet: Montag, 13. Juli 2020 10:26

> On 13.07.20 09:45, Wolfgang wrote:
> > Mit JOSM funktioniert die neue URL, schärfer wird das Bild aber
> > dadurch (jedenfalls im getesteten Ausschnitt) nicht. Sieht bei mir
> > gleich aus wie basemap Orthofoto,
> 
> Dann sind die vordefinierten Einstellungen in JOSM offenbar ungenügend.
> 
> > bloß mit ein paar cm Versatz.
> 
> Ein paar cm? Das liegt doch unter der Wahrnehmungsgrenze.

So gut ich das messen kann, ca. 30 cm. Der Versatz von geoimage zur basemap 
beträgt ca. 0.13; -0.44 (JOSM Versatz-Einstellungen).

> Ein wahrnehmbarer Versatz würde mich wundern. Als die Basemap-
> Schummerungsläyers hinzukamen und mir in Merkaartor der Versatz
> gegenüber geoimage.at auffiel, schaute ich mir das in JOSM an, und dort gab
> es keinen Versatz. Ich ging seither davon aus, dass Merkaartor da
> irgendeinen Bug hat.
> 
> Wenn du in JOSM einen Versatz siehst, wär interessant, was in JOSM
> lagerichtig ist: geoimage oder basemap?

Wie kann ich das überprüfen? DGPS?
 
> > Hab's im Wiki aktualisiert, wann das aktiv wird kann ich aber nicht sagen.
> 
> Änderungen im OSM-Wiki werden sofort aktiv, anders als in der Wikipedia,
> wo jede Änderung von einem privilegierten User freigegeben werden muss
> (und mitunter lässt das Jahre auf sich warten).

Ist schon aktiv. Eventuell muss in den JOSM-Einstellungen Refresh gedrückt 
werden.


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


Re: [Talk-at] geoimage.at geändert

2020-07-13 Per discussione Wolfgang
Mit JOSM funktioniert die neue URL, schärfer wird das Bild aber dadurch 
(jedenfalls im getesteten Ausschnitt) nicht. Sieht bei mir gleich aus wie 
basemap Orthofoto, bloß mit ein paar cm Versatz.

Hab's im Wiki aktualisiert, wann das aktiv wird kann ich aber nicht sagen.

Übrigens: seit einigen Tagen werden meine Änderungen in Mapnik nicht mehr 
gerendert, außer ich fordere die Kachel mit /dirty an (dann geht's prompt). 

LG
Wolfgang


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


Re: [Talk-us] [Tagging] Trunk VS primary

2019-12-21 Per discussione Wolfgang Zenker
* Mateusz Konieczny 
> 21 Dec 2019, 12:00 by wolfg...@lyxys.ka.sub.org:
>> I suggest to keep the road classification consistent at least within
>> a country and try to solve the problem of roads in low-zoom maps at
>> the rendering level, by modifying the list of displayed road classes
>> until a target density of displayed roads is reached. That might
>> become easier to do when we move to vector tiles.

> Seems not doable with OSM data - this
> would require far more road classes
> than we use.

Why would we need more road classes for that? This would only be an
issue if the difference between two "adjacent" classes would be so big
that you would jump from "almost none" to "to many to display" in one
step.

> lane and surface data is also almost
> certainly not helpful here even with full
> coverage

> And it would result in weird transitions
> between countries.

Only if road density changes rapidly at the border, and then we would
just depict the weird transition that exists in reality.

I think it might be possible to upgrade the "minimum zoom level to
display" on a way if there are no already displayed ways in an area,
maybe only if it connects to an already displayed way (recursive).
That way we would boost the minimum zoom level of e.g.
https://www.openstreetmap.org/way/196509120 to zoom-level 11 or maybe
even 9, even with it being just a low quality dirt track going near an
obscure archaeological site in the middle of nowhere.

Wolfgang
( lyx@osm )

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


Re: [Talk-us] [Tagging] Trunk VS primary

2019-12-21 Per discussione Wolfgang Zenker
* Joseph Eisenberg  wrote:
> Above it was said that the highway=trunk vs highway=primary
> distinction is mostly for routing applications. But allowing a proper
> rendering is also a main goal of the road tagging system.

> While it's true that road class is useful for routing when there are
> two alterate routes, a main reason to tag highways with a certain
> class is to be able to render maps properly at different zoom levels.

> When you are making a high-scale, low-zoom-level map of a large area
> (say, the whole State of Alaska, all of England, or all of Australia),
> you will want to only render highway=motorway + highway=trunk, because
> showing all highway=primary would lead to rendering many smaller roads
> which are not reasonable to show at that scale in most places.

> [..]

What makes the problem of road classification so hard is that we want it
to do different things at once. For rendering we have on the one hand
the requirement that we want to show all the "relevant" roads for a
given zoom level, on the other hand, as a map user I would expect that
a road shown as e.g. trunk in Massachusets would be quite similar in
characteristics to a road shown as trunk in Montana.

I suggest to keep the road classification consistent at least within
a country and try to solve the problem of roads in low-zoom maps at
the rendering level, by modifying the list of displayed road classes
until a target density of displayed roads is reached. That might
become easier to do when we move to vector tiles.

Wolfgang
( lyx@osm )

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


Re: [Talk-us] Opinions on micro parks

2019-10-06 Per discussione Wolfgang Zenker
Hi,

I guess we have (as so often) a problem with unconscious cultural bias
here. Property rights in Europe are generally much more limited than in
the US, e.g. in all but one(?) German states all forests are by law public
access, regardless of ownership. Also open farmland, meadows, etc.,
anything that is not fenced or walled in or immediately around houses
can normally be assumed to be public access in much of Europe, and the few
exceptions would be clearly signposted. I guess most european mappers
are not aware that the situation is different in other parts of the
world, so they simply have no idea why it could be necessary to tag a
piece of forest as a "park" to show it is a public access space.

Wolfgang
( lyx @ osm )

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


Re: [Talk-us] Historic 66 as highway=trunk in OK

2019-08-29 Per discussione Wolfgang Zenker
* Paul Johnson  [190829 14:09]:
> On Thu, Aug 29, 2019 at 6:40 AM Joseph Eisenberg 
> wrote:

>> That's probably not relevant for anywhere in the USA (even in Alaska
>> the main highways between cities are paved... right?) but it's a
>> reminder that we can certainly choose to do things in a way that makes
>> sense for mapping the USA; we don't have to use the British or German
>> standards.

> The larger cities in southern Alaska.  Most are gravel, including a paper
> interstate.  I think Alaska's the last state to still have gravel state
> highways.

Many (if not most) of Montanas "Secondary State Highways" are gravel.

Wolfgang
( lyx @ OSM )

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


Re: [Talk-at] Wie weiter mit dem Troll?

2019-07-11 Per discussione Wolfgang Schreiter

Am 11.07.2019 09:33 schrieb Florian Ledermann:

Hallo zusammen,

...
Wenn ihr es für richtig haltet die Person einfach nur zu ignorieren um
das ganze nicht weiter anzuheizen ("don't feed the troll") dann
verstehe ich das, dann ignoriert auch diese Mail gerne. Ich wollte
euch nur wissen lassen, dass ich mich ernsthaft mit dem Gedanken
spiele, die Liste zu verlassen.



Hallo Florian,

kann ich nachvollziehen, wäre aber schade.

a) Ignorieren wir das, macht er mit stillschweigender Duldung der 
Community weiter.
b) Verlassen wir alle die Liste, siehe a) und wir können uns nicht mehr 
abstimmen.


Was zu sagen war, wurde deutlich und wiederholt gesagt, 
Gesprächsbereitschaft besteht weiterhin. Konsequenzen wurden 
angekündigt. Diese müssen - beim nächsten Anlassfall - nun auch kommen.



Am 11.07.2019 10:20 schrieb Stefan Tauner:
Problematisch ist das ganze nur, weil andere auf ihn ernsthaft 
reagieren

und seiner Trollerei antworten, als wäre es eine legitime Meinung.


Ist es auch, unabhängig von ihrer Bewertung. Das Reagieren ist nicht 
problematisch, sondern essentiell, bloß sind irgendwann auch Taten 
nötig. Nicht gegen die Person, sondern zum Schutz des Ganzen. Eine 
Community, die ihre - wenigen - Regeln nicht durchsetzen kann, hat gar 
keine mehr.


LG
Wolfgang

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


Re: [Talk-at] Leider im Talk Forum

2019-06-28 Per discussione Wolfgang Schreiter


Am 27.06.2019 16:08 schrieb Wolfgang Schreiter:

Am 27.06.2019 14:42 schrieb Marc Gemis:
Is 
https://drive.google.com/file/d/1AgN1X6I9nA64syiHi6MKPdl5R-KXaRbO/view

a violation of GDPR ? You publish names, email addresses and a website
of people who probably did not give you the permission to do that.


I am not a lawyer, but according to my understanding GDPR targets
commercial entities. Private individuals and purposes are excluded.
Also, the data in the file is publicly available.


Thanks to Marc for pointing out an error in my statement. GDPR is 
applicable as stated e.g. in


https://www.privacy-regulation.eu/en/article-2-material-scope-GDPR.htm 
or

https://www.jusline.at/gesetz/dsgvo/paragraf/2,

i.e. not just for commercial entities.

Regards
Wolfgang


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


Re: [Talk-at] Leider im Talk Forum

2019-06-27 Per discussione Wolfgang Schreiter



Am 27.06.2019 14:42 schrieb Marc Gemis:
Is 
https://drive.google.com/file/d/1AgN1X6I9nA64syiHi6MKPdl5R-KXaRbO/view

a violation of GDPR ? You publish names, email addresses and a website
of people who probably did not give you the permission to do that.


I am not a lawyer, but according to my understanding GDPR targets 
commercial entities. Private individuals and purposes are excluded. 
Also, the data in the file is publicly available.


Regards
Wolfgang

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


Re: [Talk-at] Österreich Open Data Adresslisten des Bundesamt für Eich und Vermessungswesen, gejammt.

2019-06-26 Per discussione Wolfgang Schreiter



Am 26.06.2019 16:39 schrieb Johann Haag:

Prinzipiell ja. Bloß kann ich mir nicht vorstellen, dass 
Gemeindebedienstete, nachdem sie Daten nach bestem Wissen eingepflegt 
haben, OSM auswerten, um zu sehen, welche Änderungen wir nach 
erfolgtem Import daran vorgenommen haben - das ist den Aufwand 
schlicht nicht wert, sie müssten die Daten ja auch

noch extra verifizieren.

Dazu folgende Post:
https://lists.openstreetmap.org/pipermail/talk-at/2019-June/009973.html


Wieviele Gemeinden kennst Du, die das so gerne haben möchten, dass sie 
dafür sogar etwas bezahlen würden?  Und was, ganz konkret, sind deren 
Anforderungen/der erwartete Nutzen?


Frederik hat es ja schon klargestellt. Wer Daten importiert, muss den 
gesamten Abgleich der Unterschiede außerhalb von OSM bewerkstelligen, 
einschließlich der Entscheidung, welche Daten nun aktueller sind. Das 
geht nicht vom Schreibtisch aus. Innerhalb des Systems werden manuell 
und automatisch erstellte Daten gleich behandelt.

Man kann eine Initiative auch in Honig ertränken


Dann erleidet sie einen süßen Tod ;-).

LG
Wolfgang

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


Re: [Talk-at] Österreich Open Data Adresslisten des Bundesamt für Eich und Vermessungswesen, gejammt.

2019-06-26 Per discussione Wolfgang Schreiter


Am 26.06.2019 13:36 schrieb Johann Haag:

Am Mi., 26. Juni 2019 um 10:07 Uhr schrieb Wolfgang Schreiter
:


[...]

Gibt es zuwenige Mapper, dann wird eben weniger gemappt (so
bedauerlich
das sein mag). Nehmen wir mal an, alle verfügbaren öffentlichen
Daten
würden nach OSM importiert. Was dann? Wir hätten einen riesigen,
nicht
verwaltbaren Datenfriedhof, und noch weniger Mapper. OSM ist als
Mitmach-Plattform gedacht und hat keine Strukturen zum Verwalten
solcher
Datenmengen (Import, Abgleich und Verbindung mit vorhandenen Daten,
QS,
Pflege,...). Vielleicht ist das alles eines Tages überholt (was
schade
wäre) - Kritikpunkte und Krisensignale gibt es ja noch mehr (siehe
z.B.
https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/ [1]).


Diese fatalistische Sichtweise teile ich nicht, Amtliche Daten sind
keineswegs schlecht, in OSM geben wir den Leuten die einmalige Chance
solche verbessern zu können, Amtlichen Stellen erhalten als Lohn
einen Rückkanal, ein Feedback ihrer Arbeit. Ich bin mir sicher,
amtliche Stellen werden keine OSM Korrekturen so einfach in ihr
Amtliches System übertragen. OpenStreetMap liefert aber einen
Hinweis, wo Amtliche Stellen ihre Daten überprüfen sollten, und das
ist auch für Gemeinden und Städte sehr wertvoll.


Prinzipiell ja. Bloß kann ich mir nicht vorstellen, dass 
Gemeindebedienstete, nachdem sie Daten nach bestem Wissen eingepflegt 
haben, OSM auswerten, um zu sehen, welche Änderungen wir nach erfolgtem 
Import daran vorgenommen haben - das ist den Aufwand schlicht nicht 
wert, sie müssten die Daten ja auch noch extra verifizieren.



Imports sind sowieso gründlich zu überlegen, werden aber -
besonders
wenn unabgestimmt und ohne Rücksicht auf andere Beteiligte
durchgeführt
- immer zu Konflikten führen, nicht zuletzt, weil OSM eben nicht
für
Imports konzipiert ist. Weniger- und das gut - ist manchmal mehr.


OpenStreetMap ist selbstverständlich ebenso für Importe konzipiert.
Weltweit gibt es unzählige Beispiele für erfolgreiche Importe.


Frederik hat es ja schon klargestellt. Wer Daten importiert, muss den 
gesamten Abgleich der Unterschiede außerhalb von OSM bewerkstelligen, 
einschließlich der Entscheidung, welche Daten nun aktueller sind. Das 
geht nicht vom Schreibtisch aus. Innerhalb des Systems werden manuell 
und automatisch erstellte Daten gleich behandelt.


LG
Wolfgang

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


[Talk-at] Österreich Open Data Adresslisten des Bundesamt für Eich und Vermessungswesen, gejammt.

2019-06-26 Per discussione Wolfgang Schreiter
Wie man an der Anzahl an Edits in OpenStreetMap Österreich sieht, hält 
sich

hierzulande die Zahl an Craftmappern in Grenzen, umso wichtiger sind
automatisierte Verfahren.


Die Prämisse mag stimmen, die Schlussfolgerung teile ich nicht (mehr).

OSM ist kein Unternehmen oder eine vergleichbare Organisation, in der 
Ressourcen - zentral gesteuert - auf ein Ziel hin eingesetzt werden 
können. Es ist eine Gruppe von mehr oder weniger ähnlich gesinnten 
Personen, die aus persönlichen und/oder kommerziellen Gründen freiwillig 
lose zusammenarbeiten. Was immer dabei heraus kommt, ist es eben. Der 
Anspruch, der sich aus Deinen Beiträgen herauslesen lässt, ist Dein ganz 
persönlicher Wunsch, wie OSM sein sollte, nicht der Anspruch von OSM.


Gibt es zuwenige Mapper, dann wird eben weniger gemappt (so bedauerlich 
das sein mag). Nehmen wir mal an, alle verfügbaren öffentlichen Daten 
würden nach OSM importiert. Was dann? Wir hätten einen riesigen, nicht 
verwaltbaren Datenfriedhof, und noch weniger Mapper. OSM ist als 
Mitmach-Plattform gedacht und hat keine Strukturen zum Verwalten solcher 
Datenmengen (Import, Abgleich und Verbindung mit vorhandenen Daten, QS, 
Pflege,...). Vielleicht ist das alles eines Tages überholt (was schade 
wäre) - Kritikpunkte und Krisensignale gibt es ja noch mehr (siehe z.B. 
https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/).


Imports sind sowieso gründlich zu überlegen, werden aber - besonders 
wenn unabgestimmt und ohne Rücksicht auf andere Beteiligte durchgeführt 
- immer zu Konflikten führen, nicht zuletzt, weil OSM eben nicht für 
Imports konzipiert ist. Weniger- und das gut - ist manchmal mehr.


LG
Wolfgang




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


Re: [Talk-us] Someone from Boston, MA?

2019-05-01 Per discussione Wolfgang Zenker
Thanks, this was quite helpful.

* Bill Ricker  [190430 05:47]:
> On Mon, Apr 29, 2019 at 11:12 PM Kevin Kenny  wrote:
>> On Mon, Apr 29, 2019 at 11:01 PM Kevin Kenny  wrote:
>>> I'm not a Bostonian, but I've been to Copley Place.
>>> Copley Place is a named building: 
>>> https://www.openstreetmap.org/way/240501783

> This local Bostonian concurs.

> This is one of those skyscrapers with a vanity "street" address with
> no such street.
> (To confuse matters further, there is also a Copley Place Hotel whose
> address is NOT Copley Place!)

Apparently there are even two such hotels.

>> more information https://en.wikipedia.org/wiki/Copley_Place - the
>> building complex, in addition to the shopping mall, has office
>> buildings (tenants include the German and Canadian consulates, on the
>> fourth and fifth floors respectively of tower 3), hotels and a parking
>> garage, all connected.

> (and all-weather connections to adjacent malls and hotels too, and to
> two T (metro) lines and Amtrak rail.)
> (used to have a Cinema, but iirc it got consolidated out of existence?)

>> I'm not familiar enough with indoor mapping to be able to direct you
>> how to map a suite within the towers.

> A Consulate might prefer we not map the interior access?
> That level of detail is fine for retail but ... government entities
> can attract untoward attention.

I have no clue of indoor mapping myself, so I just placed two nodes in
what I estimated to be the rough location of tower 3 and tagged them as
the Canadian and German consulates.

Greetings,
Wolfgang
( lyx @ osm )

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


[Talk-us] Someone from Boston, MA?

2019-04-29 Per discussione Wolfgang Zenker
Hi,

I tried to add the German Consulate General in Boston, MA, but could not
find the address "Three Copley Place, Boston, MA 02116" in
our data. That place is apparently somewhere near Boston University.
Anyone local who could check if this is a missing street name in our
data?

consulate website: https://www.germany.info/us-en/embassy-consulates/boston

Greetings,
Wolfgang
( lyx @ osm )

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


Re: [Talk-at] Adressänderungen in Neulengbach

2019-04-23 Per discussione Wolfgang Schreiter



Zunächst ein kurzer Status-Update: aktuell habe ich knapp über 40% der 
Adressen von Tranche I (manuell) umgestellt und dabei auch die 
zugehörigen Gebäude ergänzt.


Bei Interesse (vorzugsweise von Mappern vor Ort) bitte um kurzen Post 
oder Mail damit wir uns abstimmen, um Durcheinander zu vermeiden.


Offenbar war dieser Satz in meinem vorigen Post nicht klar formuliert, 
anders kann ich mir nicht erklären, dass adresshistory.org nun daran 
gegangen ist, großflächig und offenbar automatisch Adressen rund um 
Neulengbach zu ändern. Dabei kam es - Überraschung! - zu diversen 
"Auffälligkeiten":


addr:housenumber und addr:street wurden - ersatzlos(!) - gelöscht und 
als old_*:* eingefügt. Ob das für die Hausnummer nach einem Jahr 
Gültigkeit der neuen Adressen noch Sinn macht sei dahingestellt, aber 
der Großteil der Straßenzuordnungen hat sich gar nicht geändert. Hier 
wird nur Tag-Müll produziert. Besonders ärgerlich ist aber, dass auch 
alle bereits umgestellten Adressen wieder gelöscht wurden und nun die 
richtigen Werte in old_*.* stehen. Hier ist ein Revert fällig.


addr:city wurde mit dem Gemeindenamen überschrieben. Das ist zwar nicht 
falsch, aber in der Regel wird an den Ortsnamen adressiert, wenn der Ort 
- wie am Land üblich - vom Hauptort weiter entfernt ist (das ist auch 
seitens der Post so ok). Insbesondere hat aber das Bauamt Neulengbach in 
seiner Alt/Neu-Liste die zur Straße gehörende Ortsbezeichnung 
aufgeführt, und das ist eben nicht der Gemeindename.


Zum krönenden Abschluss wurde in einer note ein Verweis auf meinen 
Original-Post angegeben. Ich lege Wert auf die Feststellung, dass ich 
mit addresshistory.org und seiner Vorgehensweise nichts zu tun habe.


Manchmal fühle ich mich so unendlich müde...

LG
Wolfgang (wolfbert)



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


[Talk-at] Adressänderungen in Neulengbach

2019-04-15 Per discussione Wolfgang Schreiter
Die Stadtgemeinde Neulengbach führt umfangreiche Adressänderungen durch. 
Betroffen sind die Postleitzahlgebiete 3061, 3051 und 3040, insgesamt 
ca. zwischen 3000 und 3500 Adressen. Dabei werden Hausnummern 
systematisch vergeben, teilweise Straßennamen vergeben und auch 
Schreibweisen bzw. Zuordnungen von Adressen zu Ortsteilen geändert. Das 
Bauamt Neulengbach stellt uns freundlicherweise Alt/Neu-Listen zur 
Verfügung.


Tranche 1 (effektiv zum 1.5.2018):

- Liste liegt mir vor, 525 Einträge
- Die Adressen sind auch schon in basemap eingetragen (allenfalls mit 
den bekannten Unschärfen), check gegen die Liste ist empfehlenswert.
- Soweit ich stichprobenartig geprüft habe, sind in OSM noch die alten 
Adressen eingetragen. adresshistory.org hat im Juni letzten Jahres 
flächendeckend Adressknoten ergänzt, aber noch mit dem Datenstand aus 
2017 (also alt).
- Ich habe einige Adressen versuchsweise angepasst (source:addr=basemap; 
Bauamt Neulengbach 20190415), geht in der Kombination 
Luftbild/basemap/Liste grundsätzlich recht gut, sorgfältiges Arbeiten 
vorausgesetzt. Bei der Gelegenheit sollte man auch gleich die Gebäude 
eintragen bzw. bestehende überprüfen, ebenfalls Straßen/Wege bzw. ggf. 
Lage/Geometrie verbessern.


Tranche 2 (effektiv zum 1.7.2019):

- Liste ist in Vorbereitung und werden wir bekommen; Umfang ist etwas 
geringer als 2018.
- Wie lange es dauert, bis die Änderungen in basemap aufscheinen, kann 
ich natürlich nicht sagen.


Tranche 3 ist geplant für 2020 mit etwa 2500 Adressen.

Bei Interesse (vorzugsweise von Mappern vor Ort) bitte um kurzen Post 
oder Mail damit wir uns abstimmen, um Durcheinander zu vermeiden.


Happy mapping
Wolfgang (wolfbert)


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


[Talk-at] POI ändern?

2019-04-06 Per discussione Wolfgang Bauer
Servus.
Bin ich berechtigt einen POI Eintrag zu ändern wenn der aktuelle Eintrag nicht mehr stimmt?
M.f.G.
Wolfgang
-- 
Wolfgang 

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


Re: [Talk-de] Radverkehrsinfrastruktur / Lübecker Modell

2019-02-05 Per discussione Wolfgang Hinsch
Am Freitag, 25. Januar 2019, 19:30:54 CET schrieb Hubert87:
> Hallo Georg,
> 
> Am 25.01.2019 um 17:58 schrieb Georg Feddern:
> > Moin,
> > 
> > nun ja - jeder benutzungspflichtige Radweg muss ja "designated"(*)
> > sein - sonst wär er ja nicht benutzungspflichtig.
> 
> Richtig.
> 
> > Andererseits sind ja nicht alle "designated" auch tatsächlich
> > benutzungspflichtig - siehe Querfeldein-Wege.
> > (Hier war die frühere StVO eigentlich besser formuliert m.M.n.)
> 
> Richtig
> 
> > Die Benutzungspflicht ergibt sich ja erst aus der Nähe/Begleitung
> > einer Straße - und kann im Wesentlichen durch "use_sidepath=yes" an
> > der Straße abgebildet.
> > Hierdurch soll ja genau das Wesentliche - nämlich die Vermeidung der
> > Straßenbenutzung beim Routing - erreicht werden.
> 
> Richtig. Der Radweg muss dann aber als eigene Linie eingezeichnet sein.

Wobei sich daraus dann in manchen Innenstadtlagen das Problem ergibt, zu 
welchem Straßenabschnitt jetzt welcher Radwegeabschnitt gehört.

Gerade in engen Innenstadtlagen würde ich daher eher von einem separat 
gemappten Radweg absehen und ihn durch tags darstellen, solange er dem Verlauf  
der Fahrbahn folgt. 

Der Unterschied ist beim Routing maßstabsbedingt praktisch bedeutungslos, 
außerdem entfällt das Problem der Abbildung von Abbiegemöglichkeiten auf der 
linken Seite.

Gruß, Wolfgang


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


[Talk-us] Open Data track at SCaLE 17x

2018-10-06 Per discussione Wolfgang Zenker
Hi,

I just noticed that the Southern California Linux Expo 2019 in Pasadena
will have an "Open Data" track. That looks like a good opportunity to
raise awareness about OpenStreetMap, so if someone would like to do a
presentation, the CfP is at https://www.socallinuxexpo.org/scale/17x/cfp

Greetings from Germany,
Wolfgang
( lyx @ osm )

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


Re: [Talk-at] addr:suburb=* korrekt eingesetzt?

2018-09-26 Per discussione Wolfgang Schreiter
Mir ist aufgefallen, dass adresshistory*org das Tag addr:suburb=* zum 
Bezeichnen von Katastralgemeinden verwendet.  Dann würde in addr:city=* immer 
der Gemeindename stehen.   Vielleicht erklärt das die Änderungen.  Das kann man 
natürlich so machen, zumindest für mich war das aber (hinsichtlich addr:suburb) 
eine Neuerung.  Habe ich da etwas übersehen, oder ist das neu?

LG
Wolfgang (wolfbert)


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


Re: [Talk-transit] tram vs. bus_guideway

2018-06-16 Per discussione Wolfgang
Am Samstag, 16. Juni 2018, 01:08:52 CEST schrieb Johnparis:
> Hello,
> 
> I've posted this question on the French transport list as well.
> 
> When examining the changesets of RB94, I found an anomaly.
> 
> https://www.openstreetmap.org/way/552199042/history
> 
> The question is: what, exactly, is a tram?
> 
> I asked TRuchin, who gave me a technical explanation. (Apparently the
> wheels are different.)
> 
> But I think this is a tram, not a kind of bus:
> 
> https://en.wikipedia.org/wiki/%C3%8Ele-de-France_tramway_Line_5#/media/File:
> T5_-_Sarcelles_-_Albert_Camus.JPG
> 
> I use the duck test. If it walks like a duck and quacks like a duck, it's a
> duck.
> 
> The RATP calls it a tram. Its name is "T6", T for Tram. So to me, it's a
> tram.

Yes, it's a tram. A bus_guideway means a way, and only a way, where the bus is 
guided by hard- or software on a particular way which cannot be used by other 
traffic, but the vehicles on this way are normal busses with an addition of a 
guide-system. They can use normal streets as well and can be steered by the 
driver as any other bus.

A tram is a vehicle which is not able to use other than guided ways of any 
kind (rails, street with guide rail, etc.). It cannot be steered individually. 
It makes no difference whether it runs on wheels of steel or tires.

> 
> Finally, if we want to use the tag highway=bus_guideway, and not
> railway=tram, we should change all the stops, because they should be:
> highway=bus_stop + public_transport=platform + bus=yes

-1

> 
> not :
> railway=tram_stop + public_transport=platform + tram=yes
> 
> Maybe a solution is:
> 
> railway=tram
> tram: type = bus_guideway
> 
> Other ideas?

railway=tram
highway=secondary(?,...) if usable by other vehicles
access=...(bus? if a bus runs on the same way)

> 
> Regards,
> 
> John

Regards

Wolfgang



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


Re: [Talk-us] Drop the tiger:reviewed tag from roads

2018-05-11 Per discussione Wolfgang Zenker
* Richard Welty <rwe...@averillpark.net> [180511 20:16]:
> On 5/11/18 2:00 PM, Doug Hembry wrote:
>> So I cast a vote for keeping it. At least don't mechanically remove them 
>> all, everywhere.

> i still use the reviewed tags for guidance as well, and would prefer
> that they
> stick around. i remove them when i've reviewed a road carefully (name,
> connectivity, location, classification, surface.)

same for me; loosing this tag would make it much harder for me to
keep track of the roads I have already reviewed/fixed and which ones are
still to do.

Wolfgang

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


Re: [Talk-us] Satus CDP

2018-02-26 Per discussione Wolfgang Zenker
* Clifford Snow <cliff...@snowandsnow.us> [180227 01:59]:
> In the middle of the Yakama Nation Indian Reservation sits Satus [1] that
> as far as I know only exists in some Census bureaucrat world. Asking around
> here I haven't found anyone familiar with the area. Wikipedia [2] doesn't
> help much either.

> I'd like to remove it from OSM. What reasonable checks do I need to do
> before deleting it. Or do they belong in OSM and I should leave it alone.

> I should add that the reason I want to delete it is because currently
> shares a boundary with the Yakama Nation. The boundary needs updating.

I would delete it, the boundary is useless. The name is still on the
place node next to what I guess used to be the railway station.

Wolfgang
(lyx @ osm)

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


Re: [Talk-us] Low-quality NHD imports

2017-10-16 Per discussione Wolfgang Zenker
Hi,

* Charlotte Wolter <techl...@techlady.com> [171016 23:50]:
>  Clifford makes some very good points. In the West, particularly,
> those little intermittent streams are important landmarks. Particularly
> when hiking in a featureless area, such as pinyon-juniper forest, a
> trail direction may say something like, "turn right after crossing the third
> drainage."
> [..]

the problem here is that at least those NHD imports I have seen in
Montana have only some of the existing streams. I don't know if this is
because NHD does not have more or because the import used not all
available streams. "Existing streams" here means both streams seen on
USGS Topo maps and stream beds seen on imagery.

Wolfgang

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


Re: [Talk-us] Trunk

2017-10-14 Per discussione Wolfgang Zenker
Hi,

it looks to me that this discussion is going in circles, not forward
at the moment. IMHO it does not make a lot of sense to argue what might
be the true meaning of "trunk". Instead, we should concentrate on what
it should mean, document this meaning if we can agree on one and don't
worry to much about what other maps or different parts of the world
think a "trunk" is.

The definition of "trunk" that I have used so far: A highway that is of
the same network importance as a primary, but specifically constructed
for fast traffic.

Wolfgang

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


Re: [Talk-us] Low-quality NHD imports

2017-10-13 Per discussione Wolfgang Zenker
Hi,

* Frederik Ramm <frede...@remote.org> [171013 08:06]:
>there's a LOT of NHD:* (and nhd:*) tags on OSM objects, see

> https://taginfo.openstreetmap.org/search?q=NHD%3A

> - 1.9 million NHD:FCode, but also 188k "NHD:Permanent_" (note the
> underscore), 10k "NHD:WBAreaComI", or 1.5m "NHD:Resolution" just to grab
> a few.

> I haven't researched who added them and when, but they would certainly
> not clear the quality standards we have for imports today. Most of this
> information can be properly modelled in usual OSM tags, and where it
> cannot, it probably shouldn't be in OSM in the first place.

> Is there any systematic (or even sporadic) effort of cleaning up these
> old imports? Is there reason to believe that the neglect extends to more
> than just the tags - do geometry and topology usually work well on
> these, or are the funny tags a huge "this whole area hasn't had any love
> in a long time" sign?

the NHD imports that I have encountered so far have numerous problems:
The data is several decades old, the so-called "medium resolution" is
pretty bad, and the data was basically just dumped into the OSM database
without any conflation happening. And larger rivers where often imported
as monstrous riverbank polygons without the river itself as a flowline.

The worst junk like lakes covering motorways has been mostly cleaned up
by now, but it is still easy to see where NHD data has been imported by
looking a KeepRights display of broken highway/waterway crossings.

I clean up the imports in areas where I'm doing TIGER reviews, but I
have to admit that a few times I have decided to work on different areas
instead because the huge riverbank polygons where almost impossible to
edit.

Wolfgang

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


Re: [Talk-us] dubious church node

2017-09-30 Per discussione Wolfgang Zenker
* Carl Anderson <carl.ander...@vadose.org> [170930 17:21]:
> ​A little history on GNIS data, and the Board of Geographic Names.

> The US Board of Geographic Names manages names for places and features
> shown on US govt maps.  They have been using a database to manage the names
> across maps and map scales. That database is the GNIS.

> The ​original GNIS data was populated from all text labels shown on USGS
> maps.  The most common source was 1:24,000 scale topo quarter quads.  Text
> from 1:100,000, 1:250,000 and 1:1,000,000 scale maps and larger were
> included.

> The stated map accuracy of these scales  (
> https://nationalmap.gov/standards/nmas.html ) is approximately

> 1:24:00040 feet
> 1:250,000 416 feet
> 1:500,000 833 feet
> 1:1,000,000   1666 feet

> The GNIS dataset includes the most precise location for text, when the text
> appears on maps of different scales.

You can look at the full database entry for an individual GNIS feature
if you search for the GNIS Feature ID at geonames.usgs.gov/apex/f?p=gnispq

This will give you the source of the database entry, possibly a list of
alternate names, sometimes a note like "location approximate", and
sometimes the history of the decision process if more than one name
had been proposed for the feature. Also documentation of official
name changes.

One more thing to know about GNIS: entries are never deleted. If a
feature no longer exists, the name gets "(historical)" appended to
it. This may have happened after the feature was imported to OSM,
so it may not show in the OSM database.

Unfortunately the GNIS database is no longer fully maintained due to
budget constraints, so you can't be sure if features still exist even
if they are not flagged as "(historical)".

As to mapping in OSM: I usually remove any "(historical)" feature.
For the others, I improve the location if possible, and if the feature
can be represented as an area, I draw that area/polygon.
Instead of deleting the original POI, I now reuse that node as part
of the outline of the feature and only move the tags to the area, so
someone looking at the object details can notice that one of the nodes
is a lot older than the others and still find the osm history of the
feature on that node.

Wolfgang
( lyx @ OSM )

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


Re: [Talk-us] NJ mass road demotions?

2017-06-12 Per discussione Wolfgang Zenker
* Richard Fairhurst <rich...@systemed.net> [170612 20:55]:
> Kevin Kenny wrote:
>> Is there *anyone* that actually can speak to what *is* common 
>> practice in the US? When I've asked, I've always drawn a lot of 
>> replies and come away more confused than before.

> I've been doing vast amounts of rural TIGER fixup over the past couple of
> years and this is what broadly seems to be what I've seen, bearing in mind
> standard practice in other developed countries and the idea that the
> highway= tag combines the importance in the highway network with some
> assurance of construction quality:

> * highway=motorway: interstate or other long-distance restricted-access road
> * highway=trunk: fast, busy State Highway or US Highway, often NHS/STRAHNET
> * highway=primary: major State Highway or US Highway
> * highway=secondary: other State Highway or major County Road
> * highway=tertiary: other through route, often a County Road, usually paved
> with centreline
> * highway=unclassified: rural minor route, sometimes a County Road, paved
> unless tagged otherwise
> * highway=residential: minor public road intended for residential access
> rather than through route, paved unless tagged otherwise
>   (N.B. currently not safe to assume paved in rural areas where
> tiger:reviewed=no)
> * highway=track: ungraded or rough, but usable by some four-wheeled vehicles

> There are many, many variations, especially because the US doesn't have a
> single nationwide system like most European countries, but if I had to sum
> it up in a few words I'd choose the above.

While most places in the US commonly use some variation of the above,
not all places use the same variation (and that wouldn't make sense
either). Using a common tagging scheme is probably much easier on a
state by state level, so we should have wiki pages describing how
suggested tagging in one specific state is different than the one
described on the US road tagging guide. We have those pages for some
states; problem is that many "drive-by-mappers" don't bother to look at
them but use their one (undocumented) criteria. One example would be a
mapper who changed all highways in Montana connecting to a port of entry
and onward to a Canadian highway to primary. Many of these are unpaved
"Montana Secondary State Highways" which I converted back to tertiary,
as described on the Montana/Highways wiki page.

Wolfgang

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


Re: [Talk-us] No updates on zoom level 12?

2017-04-04 Per discussione Wolfgang Zenker
* Clifford Snow <cliff...@snowandsnow.us> [170404 16:33]:
> On Tue, Apr 4, 2017 at 1:52 AM, Wolfgang Zenker <wolfg...@lyxys.ka.sub.org>
> wrote:

>> is there a known problem with tile updates for zoom level 12?
>> That zoom level is not updating for the area around Harlowton MT for
>> about two months now, despite marking tiles dirty several times
>> in the last 8 weeks.

> I haven't heard of any issues - what is missing?

The road from US 191 to Springwater Colony is missing, and loads of
TIGER "residential roads" show up that have been fixed many weeks
ago and should be displayed as unclassified or not at all at this
level where they really are tracks.

Also some rivers are missing like American Fork.

Wolfgang
(lyx @ osm)

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


[Talk-us] No updates on zoom level 12?

2017-04-04 Per discussione Wolfgang Zenker
Hi,

is there a known problem with tile updates for zoom level 12?
That zoom level is not updating for the area around Harlowton MT for
about two months now, despite marking tiles dirty several times
in the last 8 weeks.

Wolfgang
(lyx @ osm)

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


Re: [Talk-us] USGS Large-Scale Imagery degraded this month :(

2016-12-20 Per discussione Wolfgang Zenker
Hi,

* Russ Nelson <nel...@crynwr.com> [161221 00:21]:
> Paul Johnson writes:
>> On Sun, Dec 18, 2016 at 1:59 PM, Ian Dees <ian.d...@gmail.com> wrote:
>>> I will try to contact a couple of the folks I know at USGS (maybe they're
>>> still on this list and could respond?), but it might be the case that we
>>> need to request the imagery and build the desired layer ourselves...

>> Sounds like a plan, if only to save this valuable service for posterity.
>> I'm sure those familiar with me at this point can go ahead and fill in
>> their own frustrated and politically fueled rant about my feelings on this
>> even being something we need to be talking about now...

> Does this service degradation apply to the USGS Topographic maps, too?
> I've noticed that they load slowly and sometimes not at all.

> I can put up some money, if that's what it takes.

According to
https://www.usgs.gov/news/usgs-national-map-orthoimagery-map-services-transition-and-other-map-service-changes
the Topo maps are going away completely.

Wolfgang

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


Re: [Talk-de] Konfigurationsfehler Apache www.openstreetmap.de (WAS: Deutsche Homepage - Fehlermeldung)

2016-08-29 Per discussione Wolfgang Hinsch
Hallo,

Am Samstag, 27. August 2016, 11:06:45 schrieb lars lingner:
> Hallo,
> 
> viele Dank für das Feedback. Die SSL-Config wurde habe ich 
eben
> überarbeitet und jetzt wird die Seite mit A bei sslabs [1] 
bewertet.
> 
> Falls noch weitere Einschränkungen auffallen, bitte melden.

der Ausfall der Suchfunktion ist bekannt?

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


Re: [Talk-us] Western TIGER Roads

2016-06-03 Per discussione Wolfgang Zenker
* Alan Bragg <alan.d.br...@gmail.com> [160603 21:30]:
> [..]
> Is there any other resource? Maybe some links to well tagged areas.

I have almost finished reviewing the part of Stillwater County, MT
south of the Yellowstone River (residential roads in Absarokee are not
finished yet, and also a little bit of Reed Point).

https://www.openstreetmap.org/#map=14/45.5866/-109.3726 

So far I think my tagging there is ok (but of course I might be wrong:
when I come across areas that I worked on 5 years ago I usually find
quite some things that I do differently today; probably five years
from now that will happen in areas that I worked on now).

Wolfgang

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


Re: [Talk-us] Tagging National Forests

2016-05-09 Per discussione Wolfgang Zenker
* OSM Volunteer stevea <stevea...@softworkers.com> [160509 20:23]:
> This might sound glib, but I believe that setting landuse=forest on a 
> (multi)polygon which is land use forest is correct. [..]

I guess everyone would agree with that. The problem is that we (as in
"the mappers of OpenStreetMap") don't agree on what landuse=forest
actually means. As far as I remember we have one group that thinks
its an area set aside for growing and harvesting timber, so it can
be recognized by the presence of (planted) trees or the remains of
trees that have been recently harvested and will be replaced by newly
planted trees soon(-ish); and another group defining it as an area
where timber or small wood can be legally harvested or collected,
regardless of trees being actually or at least possibly present.
For forests using the second definition you would have to follow
official boundaries, which might be difficult to verify on the ground.

My personal preference would be to take up mapping areas covered by
trees as landcover=trees and rendering these areas the way that
landuse=forest is currently rendered, to map National Forests with
an administrative boundary and just rendering the boundary line and
deprecate landuse=forest altogether.

Wolfgang

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


Re: [Talk-us] Old Aerodromes

2016-04-12 Per discussione Wolfgang Zenker
* Andrew Wiseman <awise...@gmail.com> [160412 23:27]:
> [..]
> Or maybe there should be some tag difference between a proper airport with
> scheduled flights, a civil aviation airport, and just a field where a
> farmer might land?

Actually there is a tag, or rather there are two: The wiki page
for aeroway=aerodrome suggests to combine it with aerodrome:type=*
in the english version of the aerodrome page (used ~2000 times)
while the german version of that page suggests to use aerodrome=*
instead (used about 900 times).
Of course having two documented tags for the same purpose is not
exactly helpful which might be one of the reasons why more than
90% of mapped airports use neither one.

Wolfgang

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


Re: [Talk-us] [OSM-talk] Old Aerodromes

2016-04-12 Per discussione Wolfgang Zenker
* Paul Norman <penor...@mac.com> [160412 17:27]:
> On 4/12/2016 2:40 AM, Christoph Hormann wrote:
>> On Tuesday 12 April 2016, Martijn van Exel wrote:
>>>> I was mapping some rural area in the U.S. and noticed, not for the
>>>> first time, an aerodrome node in the middle of a field where there is
>>>> obviously no airport or airfield.

>> I am not sure here.  For small airfields the aeroway=aerodrome feature
>> is a fairly abstract thing essentially indicating only that this is a
>> place where aircrafts start or land.  This is not generally something
>> that can be reliably determined from imagery.

> You can't reliably find small airfields from imagery, but I've found it 
> possible to verify a lack of airfields from it. I pass though 
> agricultural areas, and the airfields that are still active all appear 
> somehow on imagery, even if it's just an area where the ground cover is 
> different. On the other hand, some of the aeroway=aerodrome we have data 
> for include points in fields of corn, residential areas, and stands of 
> trees.

One added problem here is that the coordinates of imported data are
not always that good. As an example check Zortman Airport
http://www.openstreetmap.org/node/1042048666
The original import was more than half a mile off.

Wolfgang

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


Re: [Talk-us] [OSM-talk] Old Aerodromes

2016-04-12 Per discussione Wolfgang Zenker
Hi,

* Martijn van Exel <m...@rtijn.org> [160412 16:29]:
> Thanks for the feedback. I understand that the existence of an small airfield 
> can be hard to verify from imagery - [..]

one more thing to check: If the node was imported from GNIS, check the GNIS
website searching for the feature id. In some cases that I have seen the
GNIS entry had moved to "historical" status since the feature had been
imported. If a feature in GNIS has "(historical)" at the end of the name
field it means the feature does no longer exist, so we can delete it in OSM.

Wolfgang

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


[Talk-us] Groups of lakes (was: Strategy for Naming Parts of a Large Park)

2016-04-10 Per discussione Wolfgang Zenker
* Kevin Kenny <kken...@nycap.rr.com> [160411 02:22]:
> [..]
> Will the same idea work with waterways?  There are a lot of places near 
> me where there's a collective name: "Preston Ponds", "Essex Chain of 
> Lakes" ...  with individual waterbodies having the unimaginative names 
> "Upper Pond," "Middle Pond," "Lower Pond" or "First Lake," "Second 
> Lake," ... "Eighth Lake".  The naming (and rendering) on those is kind 
> of messed up as well. These, too, tend to be strung out in a linear 
> formation since each chain is on a river.

I have started to tag these groups of lakes as a site relation.
One recent example would be https://www.openstreetmap.org/relation/6077541
The group is collectively known as "Hellroaring Lakes", with some
of the individual lakes having their own names and others being
unnamed. The drawback of this solution: the name of the site relation
is currently not rendered on the standard map, nor is it found by
nominatim. But I expect both to change eventually if this tagging
gets used more often.

Wolfgang

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


Re: [Talk-at] geoimage-Layer nicht mehr in JOSM

2016-03-25 Per discussione Wolfgang Schreiter
@nebulon42:

Danke für den Hinweis, habe geoimage wieder eingetragen und wird also
hoffentlich bald wieder zur Verfügung stehen.

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


Re: [Talk-de] Datenerfassung für stadtverträgliches LKW-Routing im Rheinland

2016-03-13 Per discussione Wolfgang Hinsch
Am Sonntag, 13. März 2016, 14:02:58 schrieb Martin Koppenhoefer:

> +1, wenn Kommunen ihre Routen in OSM haben wollen dann ist das 
keine Frage,
> die uns beschäftigten muss, vielmehr sollten sich dann ggf. die 
Kommunen
> mit dieser Frage beschäftigen, besonders schwierig ist sie aber auch 
nicht
> zu beantworten: entweder machen sie es selbst oder sie beauftragen 
jemanden
> damit oder sie warten, dass es Freiwillige evtl. kostenlos machen.

Wenn diese Routen nachvollziehbar von den Kommunen definiert und unter 
kompatibler Lizenz öffentlich dokumentiert werden, +1

Dann kann der Mapper vor Ort die Eintragungen prüfen. Nicht jede 
prüfbare Eintragung beruht auf einem Schild vor Ort oder der direkten 
Zugängikeit durch den Mapper.

(Busrouten, Eisenbahnrouten, PLZ, Grenzen aller Art, TMC, 
Gebäudeumrisse, Bach- und Flussläufe auf Privatgelände, ...)

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


Re: [Talk-us] Where to find airport information?

2016-03-06 Per discussione Wolfgang Zenker
* Clifford Snow <cliff...@snowandsnow.us> [160306 16:14]:
> The first example you provided is located in Stillwater County, Montana.
> Stillwater has gis data available, but unfortunately for me requires
> Microsoft Silverlight browser plugin which I am not able to run. I would
> check the county gis database for more information. The website is
> http://www.stillwater.mt.gov/GIS/default.asp

Silverlight is a no-go for me as well, I don't think it even exists
for my operating system.

> There is even someone you could contact. I find most county gis departments
> usually more than willing to help, especially if you ask nice. Even in
> counties without free data, they might be able to provide you with the name
> of the runway.

I will contact them as soon as I'm done with cleaning up TIGER geometries
in the area, because I have a few more questions (e.g. roads that look
a lot like residential roads, but with no name given on TIGER).
Thanks for the contact!

> Have you contacted the user? While it looks like a runway, I'm not certain
> that it is. Although, not sure what else it could be.

Well, the user would be myself in this case, and I added these things
as runways because that is what they look like.

> FWIW - I used to live in Montana and am familiar with parts of the state.

Great, so there are at least a few people in the project familiar
with Montana. I've been there only a few times as a tourist, and I
have been working on cleaning up TIGER geometries for Montana
basically because (almost) no-one else did. My hope is that we
find more mappers if one can start mapping without having to clean
up a lot of broken data first.

Wolfgang

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


[Talk-us] Where to find airport information?

2016-03-06 Per discussione Wolfgang Zenker
Hello everyone,

I have recently come across a few runways in Montana that I could not
find any information about except the imagery. I tried to search for
these airfields on the FAA website, but without success (maybe I did
it wrong).
Any idea where to find out more?

Two examples would be here:
http://www.openstreetmap.org/#map=15/45.4301/-109.8209=N
http://www.openstreetmap.org/#map=15/45.5226/-109.5370=N

Wolfgang

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


Re: [Talk-de] ÖPNV-Karte / Darstellung historischer Bahnstrecke

2015-10-18 Per discussione Wolfgang Hinsch
Am Samstag, 17. Oktober 2015, 13:02:34 schrieb Rolf Eike Beer:
> Am Samstag, 17. Oktober 2015, 11:25:39 schrieb goegeo:
> > Hallo zusammen,
> > 
> > mir ist aufgefallen, dass in der ÖPNV-Karte eine historische Bahnlinie
> > (blau) angezeigt wird. Es handelt sich um die ehemalige Straßenbahn
> > Flensburg, welche nur bis 1973 bestand. Mag jemand bei der 
Entfernung
> > behilflich sein. Bin im Tagging vom ÖPNV noch recht neu unterwegs. 
Denke
> > aber, dass historische Bahnstrecken nicht in der ÖPNV-Karte 
dargestellt
> > werden sollten.
> 
> Moin,
> 
> geh doch mal bitte etwas ins Detail, z.B. Koordinaten oder oder die id 
eines
> Weges, dann können wir uns das mal ansehen.
> 
> Gruß
> 
> Eike
<http://öpnvkarte.de/?zoom=14=54.79101=9.43546=TBTT
T>

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


Re: [Talk-us] OpenStreetMap US elections: October 12 townhall with candidates

2015-10-14 Per discussione Wolfgang Zenker
* Steve Coast <st...@asklater.com> [151014 17:21]:
> [..]
> A more interesting question is what should OSMFUS try to do to build editors 
> in the US, and what metric should we use (presumably active editor headcount)?

> What we’ve tried so far:
> [..]
> It feels like we should try some different things (ideas?) on a per-state 
> basis. For example, we run 100 mapping parties in Idaho and we engage 100 
> schools in Tennessee and so on so there’s distance between them and we can 
> really measure the effectiveness of anything.

> Some ideas to try:
> [..]

Thanks for steering this discussion in the direction of possible
improvements. To add a bit to Steves ideas:

I suggest to focus on the rural parts of the US instead of big cities
for a while. These are usually neglected by "the other map", looking
there shows better geometry then OSM but the same crappy, typo-infested
and incomplete TIGER based road names that we have, which tells me that
they never really looked at the area. And IMHO rural areas are where
you can win "hearts and minds" of the american people.

One idea would be to have a mapping party doing TIGER fixup for one
rural county, then contact the local newspaper, write an article what
has been done and ask for help regarding wrong/incomplete road names,
wrong data caused by outdated imagery, etc.
My guess would be that newspapers in rural towns would be happy about
every article regarding their local area that they can get.

What I noticed in many years of doing TIGER fixup in Montana is that
TIGER data in reservations is even worse than the already bad data in
other rural areas. Maybe organising mapping parties together with e.g.
a local mission inside a reservation, or working with the BIA?

Wolfgang

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


[Talk-us] TIGER layer usage limit?

2015-09-19 Per discussione Wolfgang Zenker
Hi,

currently I get error messages like

Skipping job 
http://c.tiles.mapbox.com/v4/enf.e0b8291e/17/26552/45850.png?access_token=pk.eyJ1Ijoib3BlbnN0cmVldG1hcCIsImEiOiJhNVlHd29ZIn0.ti6wATGDWOmCnCYen-Ip7Q
 because host limit reached

in JOSM while editing and trying to show the TIGER 2015 overlay.

Do I map to much? Or is this a global limit and the grand total of
people using this layer is too high?

Wolfgang

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


Re: [Talk-us] Tagging National Forests

2015-08-17 Per discussione Wolfgang Zenker
* stevea stevea...@softworkers.com [150817 20:08]:
 I am disappointed to see landuse=forest removed from the very 
 quintessence of what our wiki defines as forest: our USDA's 
 National Forests.  [..]
 [..] It does 
 not appear that a consensus is reached about this, as Martijn (and 
 what appear to be folks in the UK and Germany, largely) seem to agree 
 to remove landuse=forest, but at least Charlotte and I believe it 
 should remain.

Assuming we keep landuse=forest for the National Forests, what would
you suggest we use to tag the areas that are actually covered by trees?
And how should we render these so they can be seen as different from
areas without trees that happen to be part of a National Forest?

Wolfgang

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


Re: [Talk-at] Deklination

2015-08-11 Per discussione Wolfgang Schreiter
Hallo Friedrich,

wahrscheinlich kennst Du die Daten der ZAMG, aber schadet ja nicht:

https://www.zamg.ac.at/cms/de/forschung/geophysik/magnetik/
geomagnetische-erfassung-des-bundesgebietes-1

http://www.zamg.ac.at/cms/de/geophysik/produkte-und-services-1/
online-deklinationsrechner

Die müssten die Daten haben, ev. hilft eine Anfrage.

LG
Wolfgang

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


[Talk-at] osm bei sReal

2015-08-05 Per discussione Wolfgang Schreiter
Nur zur Info, ich fand heute einen osm-Ausschnitt in einem Immobilienangebot
von sReal (das per Mailverteiler versendet wird) und habe die
Ansprechpartnerin freundlich auf die fehlende Attributierung (nebst
Vorschlag) hingewiesen.

LG
Wolfgang


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


Re: [Talk-at] Grenzen

2015-05-27 Per discussione Wolfgang Schreiter
Ich werde mich hüten, in die Tagging-Diskussion einzusteigen, aber einige
Gedanken kann ich mir hier doch nicht verkneifen:

1.) Falls noch nicht geschehen, werft bitte einen Blick auf
http://taginfo.openstreetmap.org/search?q=name%3Aprefix#key und ebenso die
Values zu name:prefix und name:prefix:at.

Interpretation hinsichtlich Verbreitung und Verwendung überlasse ich dem
geneigten Leser.

2.) Wir taggen zwar nicht für (einen bestimmten) Renderer, aber es wäre
nützlich, auch nicht gegen (alle) Renderer zu taggen. Die Variante name
war nicht sauber, aber österreichweit umgesetzt und gerendert. Die Variante
name:prefix:at deckt etwa die Hälfte der Gemeinden und alle Bezirke ab,
ist eine Insellösung und wird nicht gerendert, wodurch die Hälfte der
politischen Grenzen nun unvollständig beschriftet sind. Das V-Wort liegt mir
auf der Zunge.

Mal angenommen es bleibt dabei, wie sieht der Plan zur Umsetzung in Mapnik aus?

3.) Wie mehrfach festgestellt, ist das Thema Namen komplex und es gibt keine
international einheitliche Lösung. Es gibt aber auch keinen unmittelbaren
Handlungsdruck (außer die Reparatur von name:prefix:at) - die Datennutzer
kommen damit zurecht. Also holt alle tief Luft, setzt Euch in Ruhe zusammen
und baut etwas (inkl. Proposal 2.0), das unsere Nachbarn auch mittragen,
dann hat das eine Chance.

LG
Wolfgang



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


Re: [Talk-at] Grenzen

2015-05-27 Per discussione Wolfgang Schreiter
grubernd lists@... writes:

 scheint wohl so ein unwichtiger InsiderKey zu sein, und damit ist es für 
 EhrlicheMapper™ weiterhin nicht existent. allein die Anzahl sagt nämlich 
 nichts über die Anerkennung eines Key aus.

Wie gesagt, die Interpretation liegt beim Leser, und das ist eben Deine.

Als Nicht-Insider kann ich die Anerkennung eines Keys leider nicht
einschätzen und bin auf Wiki, Proposals und Diskussionen angewiesen. Davon
abgesehen klärt das Aufschreiben von Konzepten die Gedanken ungemein, und
dafür gebührt Friedrich Anerkennung, auch wenn's diesmal nicht geklappt hat. 

Das Konstruieren von Texten aus positionsabhängigen Komponenten in einem
mehrsprachigen Umfeld ist grundsätzlich heikel. Für Grenzen kann das noch
eine Option sein, bei allgemeinen Namen wird's rasch sinnfrei. Jedenfalls
sollte man die Sache schon zu Ende denken, die Anzahl sagt nämlich wenig aus
;-).

LG
Wolfgang

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


Re: [Talk-at] St. Johann in Tirol... residential area... o_O

2015-05-17 Per discussione Wolfgang Schreiter
Etwas über's Ziel geschossen, würde ich sagen. Freistellen von Straßen gibt
es schon (in AT wie auch DE), wenn auch nicht mein Geschmack (die Straße ist
IMHO Teil des Gebiets, auf dem sie liegt; landuse = überwiegende
Landnutzung, ...gebiet).

Die Grundstücke sollten zumindest aber geschlossen Wohngebiet sein. Sieht
nicht gut aus und ist nicht stimmig (der Garten und der Swimming Pool sind
Wohngebiet, die - auf dem Grundstück befindliche - Garagenzufahrt aber nicht?). 

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


Re: [Talk-at] Kleingartenvereine

2015-05-15 Per discussione Wolfgang Schreiter
Tobias Knerr osm@... writes:

 Die Frage wird generell beantwortet mit: Nein, Abkürzungen in Namen
 sollten vermieden werden. Steht jedenfalls seit langem so im Wiki.

Danke für den Hinweis.

 Nun kann man bei extrem gängigen Abkürzungen noch über die
 Sinnhaftigkeit streiten (z.B. Dr vs. Doktor), aber bei den hier
 diskutierten Beispielen würde ich mich klar an die Regel halten.

Ich habe mir eben einen Überblick verschafft, welche Abkürzungen verwendet
werden. Teilweise ist die Sachlage klar, aber das Meiste wäre individuell zu
klären (und zu dokumentieren), was unabgestimmte (Massen)edits - siehe
Kleingärten - problematisch macht.

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


Re: [Talk-at] Kleingartenvereine

2015-05-14 Per discussione Wolfgang Schreiter
Dazu gibt es noch mehrere Beispiele, z.B. FF (Freiwillige Feuerwehr), VS
(Volksschule), HS (Hauptschule). Es stellt sich grundsätzlich die Frage, ob
solche Abkürzungen in Namen verwendet werden sollten.

Pro: kurz (Mappen für den Renderer?), Abkürzung in AT gebräuchlich, Name
wird nicht weiter interpretiert (welches Objekt es ist, erschließt sich ja
aus den anderen Tags).

Con: nicht erläuterte Abkürzung, steht am Objekt selbst oft ausgeschrieben.

Pragmatisch würde ich für die Kurzform im Namen plädieren.

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


Re: [Talk-de] Fußgänger-Diskriminierung?

2015-04-16 Per discussione Wolfgang Hinsch
, die Du im
 Fußgängerrouting gern vermeiden willst, muss der Renderer dann aber
 machen, will er seien Job gut machen - hat dieser Fussweg hier zufällig
 den gleichen Namen wie eine benachbarte Straße, für geeignete Werte von
 'benachbart', dann schreibe den Namen nicht extra rein.

Das ist das gleiche Problem bei getrennten Fahrbahnen und bei Radwegen. 
Einerseits die Raterei, zu welcher Straße die Wege gehören, andererseits die 
Namen auf mehreren Ways.

Ein weiteres Problem für den Renderer besteht darin, dass die Rad- und Fußwege 
mit Verkleinerung des Maßstabes unter oder über die Signatur der Fahrbahn 
geschoben werden. Entsprechend sehen die Karten dann auch aus, die Radwege 
liegen wie eine Straßenbahn in der Fahrbahnmitte.

Gruß, Wolfgang

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


Re: [Talk-us] [Imports] Importing Tesla Superchargers

2015-04-12 Per discussione Wolfgang Zenker
* Charles Samuels o...@charles.derkarl.org [150412 22:21]:
 On Sunday, April 12, 2015 01:12:12 AM Andy Allan wrote:
 Right now, if a tag doesn't match with supercharge.info, I overwrite
 OSM's.

 Could you explain this a bit further? For example, if supercharge.info
 has capacity 6, and I correct this to capacity 8, does your script
 then overwrite my tag and change it back to the incorrect value?

 Correct. My intent is that I expect OSM to be no better than 
 supercharge.info, 
 so for now it's easiest to just overwrite. Then on following runs of it, I 
 manually investigate the changes made in OSM and reconcile the differences.

Sounds like the perfect way to drive away mappers, in other words: a pretty
bad idea. Investigating existing differences and reconciling the two data
sets looks like a much better (and acceptable) way to me.

Wolfgang

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


Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht

2015-04-07 Per discussione Wolfgang Hinsch
Am Sonntag, 5. April 2015, 16:51:16 schrieb fly:
 Hast Du nicht den Datensatz runtergeladen ?
 War da eine Lizenz dabei ?
 
 Falls nicht, hast Du den Satz als CC0 runtergeladen und der bleibt auch
 CC0, selbst wenn die Lizenz jetzt geändert ist.
 

Du meinst wahrscheinlich, ob eine von der auf der Seite zu dem Zeitpunkt 
angegebenen CC0-Lizenz abweichende Angabe im Datensatz war.

(Ganz ohne Lizenz  CC0)

Grundsätzlich ist das erst mal richtig, aber:

Es handelt sich sehr wahrscheinlich um einen Irrtum. Dies ist von uns bemerkt 
worden. Ob wir die Beute trotzdem einfach behalten und verwerten dürfen, ist 
fraglich. Bei der sehr zurückhaltenden OSM-Politik in diesen Bereichen 
zumindest im Projekt eher nein.

Außerdem halte ich es im Sinne eines Miteinanders mit der Verwaltung, bei der 
sich jetzt endlich etwas ändert, für kontraproduktiv, jeden Brocken, der mal 
versehentlich etwas daneben geworfen wurde, sofort mit Zähnen und Klauen zu 
schnappen und festzuhalten. Es gibt mit Sicherheit innerhalb der Verwaltung 
unterschiedliche Positionen und wir würden nur die Fraktion stärken, die 
sowieso der Meinung ist, die Piraten von OSM klauen sofort alles, was nicht 
niet- und nagelfest ist.

Im übrigen ist uns die Verwaltung schon sehr weit entgegen gekommen. Der in 
der Lizenz geforderte Quellenverweis muss nur angegeben werden, wenn er vom 
Datenanbieter bereitgestellt wird, und der schreibt ausdrücklich 
Namensnennung nicht erforderlich. 

Siehe auch Mail vom 2.4.15

Gruß, Wolfgang

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


Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht

2015-04-02 Per discussione Wolfgang Hinsch
Am Donnerstag, 2. April 2015, 14:22:04 schrieb Johannes Kröger:
  Für die Datenlizenz Deutschland Namensnennung 2.0 finde ich bei uns
  keine belastbare Aussage, ob das Ding nun kompatibel ist oder nicht.
 
 Dito. :( Die Namensnennung im Changeset und der Homepage wird kaum
 gerecht sein, sie infiziert ja die Daten und muss erhalten bleiben.
 
 Sonst wären da wirklich tolle Daten verfügbar, Teile von ALKIS,
 Adressen, Gebäudegrundrisse etc. Die wären toll zum vorsichtigen
 Abgleichen.
 

Möglicherweise ist zwar die Deutschland-Lizenz 2 prinzipiell nicht kompatibel, 
aber in diesem Sonderfall schon. Laut Lizenz müssen die Pflichtangaben vom 
Anbieter der Daten bereitgestellt werden, wenn er sie verlangen will. Dieser 
Anbieter schreibt aber nur Namensnennung nicht erforderlich, ansonsten sehe 
ich da keine weiteren Forderungen.

Ich gehe davon aus, dass hier bewusst verzichtet wird. Darauf deutet auch die 
zunächst genutzte CC0. Dies ist jetzt gewissermaßen die amtliche CC0.

Gruß, Wolfgang

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


Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht

2015-04-01 Per discussione Wolfgang Hinsch
Hallo,
Am Dienstag, 31. März 2015, 20:27:40 schrieb Johannes Kröger:
 Ich habe zwar noch keine Antwort von irgendwem offiziellen bekommen,
 aber der Datensatz (und die anderen CC0er) ist jetzt wie alles andere
 unter der Deutschlandlizenz. Da hätte ich wohl abwarten sollen, bevor
 ich es geschrieben habe, sorry!
 
 http://suche.transparenz.hamburg.de/dataset/hamburger-strasseninformationsba
 nk-hh-sib
 

Für die Datenlizenz Deutschland Namensnennung 2.0 finde ich bei uns keine 
belastbare Aussage, ob das Ding nun kompatibel ist oder nicht.

Ich vermute mal, dass schon einige Leute munter am Abpinseln sind.

Gruß, Wolfgang

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


Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht

2015-03-30 Per discussione Wolfgang Hinsch
Am Montag, 30. März 2015, 13:07:00 schrieb Martin Koppenhoefer:
 Am 30. März 2015 um 12:47 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:
  Ich frage aber doch mal nach:
  
  Reicht die Lizenz für uns aus?
  

 
 wieso, da steht doch cczero, mit link:
 http://creativecommons.org/publicdomain/zero/1.0/deed.de
 das heisst, es gelten überhaupt keine Auflagen, Du kannst damit machen, was
 Du willst (wie Public Domain). Namensnennung ist nicht erforderlich.

Hups, da hast du recht :)

Ich bin durch das crossposting da etwas von der Schiene gekommen. Es ging in 
einem anderen Thread auf talk-HH darum, ob die noch interessanteren 
Kreuzungsskizzen[1] ausgewertet werden dürfen, die stehen unter der 
Datenlizenz Deutschland – Namensnennung – Version 2.0 [2], bei der ich mir 
nicht so sicher bin.

Gruß, Wolfgang

[1] http://suche.transparenz.hamburg.de/dataset/kreuzungsskizzen-hamburg
[2] https://www.govdata.de/dl-de/by-2-0

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


Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht

2015-03-30 Per discussione Wolfgang Hinsch
Am Freitag, 27. März 2015, 13:36:25 schrieb Martin Koppenhoefer:
  Am 26.03.2015 um 19:03 schrieb Johannes Kröger
  johannes.kroe...@hcu-hamburg.de:
  
  Besonders bei solchen manuell eingestellten Daten. Sind
  doch alles auch nur Menschen. Es sind nur drei Datensätze mit CC0 im
  Transparenzportal, während alles andere unter der Deutschlandlizenz
  steht. Da sollte man erstmal sichergehen, dass sie wirklich so gedacht
  sind.
 
 wenn sie sie mit dieser Lizenz veröffentlichen dann sollte die wohl auch
 gelten, der Sinn einer Lizenz ist ja gerade, dass man nicht mehr nachfragen
 muss.

Ich frage aber doch mal nach: 

Reicht die Lizenz für uns aus? 

Was ist mit dem Quellenverweis für Abwandlungen, also das, was wir daraus 
machen? 
Wir können das im Kommentar zum Changeset unterbringen, aber derjenige, der 
die Daten von uns runterlädt, hat den Verweis nur, wenn bei jedem Objekt im 
Sourcetag der Quellenverweis auftaucht, was wohl praktisch kaum zu leisten 
ist.

Vor allem aber: Was ist mit Abwandlungen von Abwandlungen (Weiterverarbeitung 
unserer Daten)? 

Reicht ein Quelleneintrag auf der Quellenseite unseres Wiki?

Muss der Downloader in seinen Anwendungen wiederum den Quellenverweis 
mitführen?

Gruß, Wolfgang

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


Re: [Talk-de] heise berichtet ueber osm.org-Routing integration

2015-02-20 Per discussione Wolfgang Hinsch
Am Freitag, 20. Februar 2015, 00:32:24 schrieb Patrick Niklaus:
  Ich würde OSRM von der Auswahl entfernen, bis sie z. B. auch
 
 Abbiegerelationen und Anliegerstraßen beachtet, die gehören meiner Meinung
 nach zu den Grundfunktionen.
 
 Falls du Abbiegerelationen findest die nicht funktionieren, dann poste das
 bitte hier [1]. Momentan nicht unterstützt werden lediglich
 Abbiegerelationen bei den via ein Way ist.

Was schade ist, denn an dieser Stelle 

http://www.openstreetmap.org/directions?engine=osrm_carroute=53.60779%2C10.03524%3B53.60774%2C10.03872#map=18/53.60797/10.03697

gibt es dazu keine Alternative. Am Ende der Verkehrsinsel beginnt nahtlos eine 
Busspur, die nicht gequert werden darf. Rechtsabbieger müssen also rechts an 
der Verkehrsinsel vorbei fahren, alle anderen links. Google behilft sich mit 
falscher Straßendarstellung, die können es also auch nicht. Hätte OSM also die 
Nase vorn haben können...

Gruß, Wolfgang


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


Re: [Talk-de] Wieder einmal lcn Sammelrelationen

2015-02-10 Per discussione Wolfgang Schuch

Hallo zusammen,

leider komme ich nur selten dazu diese Liste hier zu lesen, habe aber 
diese Diskussion gesehen und mal gelesen. Und da ich beruflich mit 
Radwegweisung zu tun habe, könnte ich dazu was beitragen.


Diese hier immer wieder erwähnte Wegweisung (WW) ist nicht x-beliebig. 
Sie ist seit 1998 die durch die FGSV festgelegte Norm

http://www.fgsv-verlag.de/catalog/product_info.php?products_id=433

Für ihren Einsatz braucht es eine Netzplanung nach ERA
http://www.fgsv-verlag.de/catalog/product_info.php?products_id=2869

Bundesweit ist sie meist grün auf weiß, in Teilen von Niedersachsen auch 
rot auf weiß wie in ganz NRW. Dort ist sie sogar Teil der StVO-Wegweisung.


Diese WW hat mehrere Komponenten:
ZwischenWW
http://www.stempelcity.de/l8mimages/zwischenwegweiser.jpg
die stehen grob dort, wo es nur in eine Richtung weiter geht.

HauptWW
http://www.gruene-koengen.de/bilder/radweg/piktogramme.anordnung.png
die solche PfeilWW sein können, aber auch entsprechende TabellenWW
http://www.wfg-rd-eck.de/uploads/Tourismus/Bsp.%20Tabellenwegweiser_1.jpg
Beide stehen dort, wo es in mehrere Richtungen geht.

Nur auf den HauptWW stehen Zielorte (oben Fernziel, unten Nahziel) mit 
km Angabe. Zudem können vor dem Ziel noch Zusatzangaben zum Ziel (z.B. 
(S-)Bhf, Schwimmbad, ...) stehen, die sich dann bei Bedarf in der Nähe 
des Ziels aufsplitten. Zwischen Zielort und km können noch Zusatzangaben 
zum Weg sein (viel Autoverkehr, Steigung oder Baum für nicht 
alltagstauglich).


Routen werden als Signet unten im HauptWW eingehangen. Sie sind in der 
Regel touristisch.


Da es sich bei der WW um eine offizielle ;-) handelt, wollen auch alle 
Offiziellen mitreden, d.h. sie muss abgestimmt werden und viele 
Bedenkenträger können alle möglichen Einwände einbringen, weshalb auf 
einer für den Radverkehr gut geeigneten Strecke keine WW erscheinen 
darf. Daher sind derartige Netze immer suboptimal, aber offiziell.


Und es muss noch erwähnt werden, dass das hier beschriebene idealtypisch 
ist. Die Realität sieht nicht selten anders aus. Schlecht und/oder 
regelwidrig geplant, nicht gewartet und daher lückenhaft, oder durch 
Bauarbeiten unterbrochen und nicht wieder hergestellt. Aber das gibt es 
auch (zwar geringer) bei PKW-WW. Nur dort fallen Fehler eher auf, da die 
Planer mehr Auto als Rad fahren ;-)


Aber eigentlich ;-) müssten die Kommunen, Kreise oder Länder, die diese 
Netze geplant haben, davon auch Unterlagen über den Sollzustand ohne 
Fehler im Gelände haben, die abrufbar sein sollten. Damit wären die 
Netze auch leichter zu taggen.


Dabei will ich es gerade belassen, weil ich ins Bett muss. Für Fragen 
stehe ich gerne zur Verfügung. Falls ich hier in der Liste nicht 
antworte, schreibt mir gerne ne PM.


tschau und gute N8
Wolfgang

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


Re: [Talk-de] Abkürzungen für die Radwege in OCM

2015-01-30 Per discussione Wolfgang Schuch

Hallo Michael,


Das stimmt nicht ganz. In kleinen Teilabschnitten existiert er schon,
teils aber nicht im geplanten Ausbauzustand. Den genauen geplanten
Verlauf findet man in der Machbarkeitsstudie:
http://www.rs1.ruhr/fileadmin/user_upload/RS1/pdf/RS1_Machbarkeitsstudie_web.pdf
(20MB)


Bitte beachten:
1. We map what's on the ground. Das heißt Ways werden nur dann in die
Routenrelation aufgenommen, wenn sie fertig sind (ansonsten ist es ein
propsed- bzw. construction-Route). Die Machbarkeitsstudie ist ein
Planung. IMHO sollte man geplante Sachen frühestens mappen, wenn das
Planfeststellungsverfahren läuft.
2. Urheberrecht. Haben wir eine Nutzungerlaubnis für die Machbarkeitsstudie?


Die Information, wo der RS1 lang gehen wird, unterliegt nicht dem 
Urheberrecht. Wenn überhaupt, dann nur das Schriftstück, nicht sein Inhalt.


Und wie gesagt: es gibt schon Teilstücke z.B. in Essen, teils in noch 
nicht fertigem Ausbauzustand. D.h. z.B. kein Asphalt und/oder nicht so 
breit wie geplant.


Wenn OSM aber wirklich nur mit Wegweisung ausgeschilderte Strecken 
abbilden will, dann ist es meist noch nicht soweit. Gibt es eine 
derartige Festlegung?


fragt
Wolfgang

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


Re: [Talk-de] Abkürzungen für die Radwege in OCM

2015-01-30 Per discussione Wolfgang Schuch

Hallo zusammen,

 Den gibt's doch noch garnicht:

http://www.schmidts-katze.info/2014/radschnellweg-ruhr-110-mio-e-fuer-100-km-radweg/


Das stimmt nicht ganz. In kleinen Teilabschnitten existiert er schon, 
teils aber nicht im geplanten Ausbauzustand. Den genauen geplanten 
Verlauf findet man in der Machbarkeitsstudie:
http://www.rs1.ruhr/fileadmin/user_upload/RS1/pdf/RS1_Machbarkeitsstudie_web.pdf 
(20MB)



Ansonsten wuerdest du ihn auf http://cycling.waymarkedtrails.org/ finden


Da ist er noch nicht verzeichnet

Gruß
Wolfgang Schuch



2015-01-29 14:16 GMT+01:00 Bernd Sommer gabes...@me.com:


Hallo zusammen


Kann ich irgendwo nachlesen, welche Abkürzungen die einzelnen Radwege

auf den „Open Cycle Map`s“ haben?

Wie finde ich den RS1-Radweg von Duisburg nach Dortmund?


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


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





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


Re: [Talk-us] GNIS POI populations

2015-01-28 Per discussione Wolfgang Zenker
* Minh Nguyen m...@nguyen.cincinnati.oh.us [150128 09:12]:
 [..]
 It doesn't sound like Paul was proposing to systematically eliminate 
 place=hamlet POIs. It sounds like he was evaluating each one on its merits.

 I do delete GNIS POIs fairly regularly, but not just because they're 
 tagged place=hamlet. It's usually because it's a mobile home park that I 
 can turn into a more accurate landuse=residential. Or it's the name of a 
 railroad junction torn out a century ago that now sits in the middle of 
 wilderness. (There is place=isolated_dwelling in the event that a small 
 cluster of houses is still called by that name.)

I used to delete these now unpopulated railroad junction POIs earlier,
but nowadays I just reclassify them as place=locality because the names
seem to be still in use in many cases.

Wolfgang

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


Re: [Talk-us] GNIS POI populations

2015-01-13 Per discussione Wolfgang Zenker
* Richard Fairhurst rich...@systemed.net [150113 19:50]:
 Minh Nguyen wrote:
 I think we should consider a mechanical edit to update these tags

 While you're thinking about GNIS mechanical edits, could I suggest one for
 GNIS-sourced POIs with (historical) in the name?

 There are several gazillion amenity=post_office, name=Fred Creek Post Office
 (historical) in the database. Clearly these aren't actually post offices any
 more. Ideally I guess they should be disused:amenity=post_office, or
 historic:amenity, or something.

 https://www.google.co.uk/search?q=site%3Aopenstreetmap.org+gnis+historicalgws_rd=ssl

 I'd do it myself but this is about the one area where you _do_ need JOSM
 rather than P2. ;)

In Montana I have removed rather than changed these POIs, as they definitely
no longer existed before the GNIS import. Removing these for all of the US
would be a good thing, especially for hospitals. We definitely don't want
people in an emergency to end up in the middle of an empty field because
they followed their navigation device to Podunk Hospital (historical).

Checking the other POIs if they have been changed to (historical) status
since the import might also be a good idea.

Wolfgang

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


Re: [Talk-de] cycleway=track bei Bordstein Trennung

2014-12-30 Per discussione Wolfgang Hinsch
Am Montag, 22. Dezember 2014, 13:28:16 schrieb huey212:
 Hallo, folgende Gedanken:
 
 ich mappe sehr viel Radverkehrspezifisches. Da stellt sich mir die
 Frage, was haben Radwege und (Auto-)Fahrbahnen gemeinsam?
 
 -ggf. einen Bordstein,
 -grob den gleichen Verlauf,
 -den gleichen Straßennamen,
 -die gleiche Beleuchtung
 
 Was ist unterschiedlich?
 
 -Der Verlauf im Detail
 -Fahrbahnbelag,
 -Nutzungsvorgaben (access)
 -Einbahnstraßenregelungen (Fast alle straßenbegleitenden
 innerstädtischen Radwege in Deutschland sind Einbahnstraßen! Fußwege
 hingegen nicht.)
 -Spuraufteilung
 -Abbiegebeschränkungen
 
 Ich halte das Anbringen von Fuß- und Radweginformation an der
 Hauptfahrbahn nur bei relativ grobem Mapping für sinnvoll. Sobald es in
 die Details geht sollte die Wege als einzelne Linienzüge erfasst werden.
 Alles andere wird unübersichtlich und ist nicht mehr editierbar (weil zu
 kompliziert). Von einer sinnvollen Auswertung reden wir mal noch gar nicht.

Die sinnvolle Auswertung besteht meistens aus einer Karte oder einem Router.

Die Karte hat, wenn gedruckt oder sonstwie als Übersicht genutzt, einen 
Maßstab, in dem die Symbole von Fahrbahn und Radweg sich gegenseitig 
verdecken. Man kann zwar im Web weiter hineinzoomen, einen Nutzen hätte das 
aber nur für eine Art Straßenkataster, das wir ohnehin nicht leisten können.

Der Router braucht verbundene Wege, um alle Abbiegemöglichkeiten nutzen zu 
können. Das wird häufig ausgelassen, wenn nur auf der Gegenseite ein Weg 
abzweigt.

Die Zuordnung des Radweges zu einer bestimmten Straße ergibt sich im 
innerstätischen Bereich aus der reinen Lage nicht immer. 

Daher meine ich, dass der Radweg, wenn er keine erheblich andere 
Streckenführung als die Straße selbst hat, an sie getaggt werden sollte. Das 
eigenständige Einzeichnen hat in hohen Zoomstufen einen optisch schönen Effekt, 
besonders im Zusammenwirken mit dem Luftbild, ist aber für die meisten 
Auswertungen eher hinderlich.

Als Ausweg bliebe noch, den straßenbegleitenden Radweg, wenn man es denn 
unbedingt möchte (und solange es überhaupt noch so etwas gibt), sowohl als tag 
als auch als eigenständigen Weg einzuzeichnen und dem Auswerter über eine 
Relation (street) oder über ein Tag (?) mitzuteilen, dass er sich hier die für 
ihn günstigere Variante aussuchen kann.

Übrigens gilt für den straßenbegleitenden Fußweg sinngemäß das Gleiche. Wenn 
der Radweg unbedingt ein eigenständiger Weg sein soll, müsste der Fußweg 
analog ebenfalls eigenständig eingezeichnet werden. Die Argumente sind 
letztlich die Gleichen, mit allen Vor- und Nachteilen.

Ob aber 5 Linienzüge im Verlauf einer Straße übersichtlicher als ein einzelner 
sind, muss wohl jeder Mapper für sich selbst entscheiden. Einen guten Editor 
(mit gutem css-Stil) vorausgesetzt, dürfte das Modell mit den Tags 
übersichtlicher darstellbar sein als das Modell mit den separaten Wegen. Dann 
erscheinen die Rad- und Fußwege optisch am Außenrand der Straße. Was bleibt, 
sind die längeren tags, dafür aber alle an einem Way zusammengefasst und nicht 
an 5 Ways verteilt. Auch hier kann ein guter Editor viel Übersicht schaffen.

Wenn wirklich die Straße genau abgemalt werden soll, halte ich eine 
zusätzliche Flächenerfassung für sinnvoller. Letztlich ist das die einzige 
Möglichkeit, in hohen Zoomstufen (und nur dort) die Straße mit allen 
Einzelheiten abzubilden. Auch dann bleibt aber die Frage, wer das eigentlich 
braucht, außer als schöne Ansicht.

Gruß, Wolfgang

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


Re: [Talk-de] cycleway=track bei Bordstein Trennung

2014-12-16 Per discussione Wolfgang Hinsch
Am Samstag, 13. Dezember 2014, 00:41:23 schrieb Hubert:
 
 Der Renderer, welcher den Bürgersteig an der Straße darstellen möchte,
 unterdrückt halt alle highway=footway + footway=sidewalk und stellt die
 highway=residential + footway:both=sidewalk entsprechend dar. Z.B. als
 roten Rand. Derjenige, der den Bürgersteig als eigenen Weg darstellen will,
 malt die highway=residential + footway:both=sidewalk als normale Straßen,
 ohne roten Rand, und stellt darfür die highway=footway +
 footway=sidewalk dar. So oder so ähnlich.
 

Damit der Renderer erkennen kann, dass die extra-Fußwege an die Straße gehören 
und er sich somit die (für den Maßstab) passendere Variante aussuchen kann, 
sollten es eine street-Relation geben, in der alle Linien, die zur gleichen 
Straße gehören, erfasst sind. Das erleichtert auch die Zuordung von 
Straßennamen etc. zu separaten Wegen.

Auf dem gleichen Weg kann auch die Diskussion um die separaten oder nicht 
separaten Radwege gelöst werden. Der Datenkonsument kann sich dann frei 
aussuchen, welche Lösung er für sich für geeigneter hält.

Gruß, Wolfgang

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


[Talk-de] Erstellung kml-Dateien mit Markern

2014-11-17 Per discussione Wolfgang Wienke

Hallo,
gibt es eine OSM-Seite mit einem Straßenkarte, auf der man - ähnlich wie 
mit GoogleEarth  über einem Luftbild - Marker eintragen kann, diese mit 
Namen und Beschreibung erweitern kann und letztendlich alles in einer 
kml-Datei speichern kann?


--
   mit freundlichen Grüssen

 Wolfgang Wienke

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


Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)

2014-11-13 Per discussione Wolfgang Hinsch
Hallo,

Am Mittwoch, 12. November 2014, 09:49:45 schrieb Joachim Kast:

 
  ... denn von dem Network-Vorschlag  halte ich persönlich für nicht optimal
  (Änderung eines Verwendungszweckes eines Tag's, müsste auch erst
  ausführlich diskutiert werden).
 Es mag sein, dass network=* nicht so optimal ist, aber mir fällt
 momentan auch nichts besseres ein. Bei der Analyse der
 network-Werteverteilung [1] findet man jedoch so ein wohlgeordnetes
 kreatives Chaos, dass es auf ein network=eBusinesslotse eigentlich auch
 nicht mehr ankommt.
 
 Ziel dieser wie auch immer aussehenden Kennzeichnung soll sein, die
 dezentral eingegebenen Daten für eine App einzusammeln. Das könnte man
 prinzipiell auch über die Auswertung des Anfangs des Name-Tags bei einer
 einheitlichen Namensgebung machen, aber ich finde eine eigene key/value
 Kombination dennoch besser.
 
 
 Sollte jemand eine optimalere Lösung anstatt network=eBusinesslotse
 haben, dann möge er seinen Vorschlag hier bitte präsentieren.
 

Letztlich läuft es immer wieder auf das gleiche Problem hinaus, über das seit 
mehreren Jahren diskutiert und für das immer wieder eine Lösung abgelehnt 
wurde: Eindeutige Verweise auf OSM-Daten aus anderen Datenbeständen heraus.

Alles schreit nach externen Datenbanken (Nicht alles in OSM kippen), aber 
eine Lösung gibt es bis heute nicht, so dass letztlich Insellösungen gebastelt 
werden, die individuell Tags festlegen, mit denen dann die Daten 
referenzierbar sein sollen. Wenn das so weiter geht, haben wir bald ein 
schönes Sammelsorium von verschiedensten Tags, für jede Anwendung ein paar.

Ich schlage daher vor, über _ein_ objektbezogenes Referenz-Tag nachzudenken, 
dass in eindeutiger Form, wo notwendig, vergeben wird und das dann jeder 
Nutzer für seine Anwendung benutzen kann.

Ich werfe mal ein Tag in den Ring:

externel_reference_id=[nwr]{derzeitige-id-Nummer}

also ein Tag, das bei Bedarf jederzeit mit den Editoren erzeugt werden kann 
und dessen Wert einfach der derzeitigen Objekt-ID entnommen wird,
also z.B. für Ways 

externel_reference_id=w1234567890

ERID im Folgenden

Für Relationen und Nodes eben mit n bzw. r

Ich könnte mir vorstellen, dass es ohne besonderen Aufwand möglich wäre, die 
Editoren entsprechend zu erweitern. Das Tag sollte nur vergeben werden, wenn 
tatsächllich Bedarf für eine externe Refernenz besteht, dann aber einheitlich 
von allen Interessenten nutzbar sein.

Vorteil gegenüber dem heutigen Gebastel: Ein Tag für alle und gut.
Vorteil gegenüber der ID direkt: Wird das Objekt geteilt oder verschmolzen, 
bleibt das Tag im Gegensatz zur ID erhalten, es überlebt auch eine Änderung 
des Datentyps, z.B. von Node auf Way. 

Natürlich bleiben noch Fragen. Was passiert, wenn zwei Referenzobjekte 
verschmolzen werden.

Man könnte die ERIDs dann mit Trennern aufzählen, aber das führt 
möglicherweise zu Datensalat.
Besser wäre es, wenn das neue Objekt eine eigene ERID bekommt oder eine der 
ERIDs fortführt. Die Kontinuität ist gegeben,wenn in der letzten Version der 
untergehenden ERID ein Tag mit einem Hinweis auf die Folge-ERID gesetzt wird.

Eine Abfrage nach einer Referenz muss also immer nach der ERID mit der 
maximalen Versionsnummer suchen. Steht dort ein Verweis auf die neue ERID, 
wird im Datenbestand des Nutzers der Verweis entsprechend aktualisiert und er 
sucht nach dem Datensatz mit der neuen ERID.

Letzlich also: Extern verlinkte Objekte haben 2 zusätzliche Tags (ERID und 
ERID-Version), und damit gut für alle. 

Nur für den Fall, dass der Verweis in ein anders Objekt überführt wurde 
(Verschmelzung etc.), gibt es in der letzten Version des alten Objekts ein 
extra-Tag mit einem Hinweis auf die neue ERID.

Der Vorschlag ist nicht perfekt und nicht zu Ende gedacht. Ich habe das jetzt 
nur mal so aus dem Ärmel geschüttelt, aber wenn echtes Interesse an einer 
endgültigen Lösung besteht, könnte man ein Proposal im Wiki anlegen und die 
Sache von allen Seiten beleuchten.

Gruß, Wolfgang

(der das Problem auch schon hatte)

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


[Talk-de] Bing-Layer mit OSM-API V3

2014-11-06 Per discussione Wolfgang Wienke

Hallo,
ich habe obiges versucht, die Anzeige des Luftbildes klappt auch mit:

varmap = new ol.Map({
target: 'map',
layers: [ new ol.layer.Tile({ source: new ol.source.BingMaps({
key: mein Key,
imagerySet: 'AerialWithLabels' })
})
],
	view: new ol.View({ center:  	 
ol.proj.transform([6.10428,50.76079], 'EPSG:4326', 'EPSG:3857'),

zoom: 11 }),
}); 

Ich bekomme aber keine controls und keine attribution hin, was ich auch 
eingebe.




--
   mit freundlichen Grüssen

 Wolfgang Wienke

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


Re: [Talk-de] Karte auf openstreetmap.de defekt

2014-10-24 Per discussione Wolfgang Hinsch
Hallo

Am Donnerstag, 23. Oktober 2014, 19:27:07 schrieb Pascal Neis:
 Hi,
 
 Wolfgang Hinsch schrieb:
  Von mir aus kann es auskommentiert bleiben. Wer brauchts?
 
 die Idee dahinter kennst du?
 
 Wir (Frederik  ich) hatten eigentlich vor zwei Jahren [1]
 etwas ähnliches geplant was vor kurzen von jemand anderem unter
 dem Titel Predicting data curation in OpenStreetMap[2] gezeigt
 wurde.
 
 Also auf Basis der Information WO sich jemand die online Karte
 ansieht und den Infos z.B. von der Bevölkerungsdichte Statistiken
 zu generieren wo evtl. eine gute oder schlechte Vollständigkeit
 vorliegt.

 [1] http://www.remote.org/frederik/tmp/ilike.pdf
 [2] https://www.mapbox.com/blog/osm-tracing-candidates/

Diese Idee hätte allgemein ersichtlicher kommuniziert werden sollen. Mein 
persönlicher Eindruck war, dass dieser Spielkram den Gesamteindruck der 
Präsentation der Karte ruiniert hat.

Vielleicht wäre eine geschicktere Gestaltung mit mehr Abstand zu 
Gesichtsbüchern eine Abhilfe gewesen.

Nebenbei: An der Darstellung von Mapbox überrascht mich nichts, außer 
vielleicht, dass die Ex-Position von Lummerland ein Hotspot ist :-)
Die meisten Informationen hätte ich mir auch so vorstellen können.

Außerdem - Der Unterschied zwischen uns und kommerziellen Kartendiensten ist 
ja gerade der, dass es uns egal ist, wo wer wie oft sich die Karte ansieht. 
Bei uns wird da gemappt, wo der Mapper hinfällt (vor Ort ist/Lust 
hat/Luftbilder gut sind/...). Auf sehr lange Sicht ist unser Ziel (aus meiner 
Sicht) eine einigermaßen gleichmäßige Erfassung weltweit, im Gegensatz zum 
kommerziellen Anbieter, der sich die Frage stellen _muss_, wie weit aufgelöst 
die Karte wo angeboten werden sollte. Bei OSM wird das letzte Wigwam der 
Mohikaner - falls ein Mapper vorbeikommt - mit der gleichen Sorgfalt und 
Akribie aufgenommen wie der Times Square in New York.

Gruß, Wolfgang

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


Re: [Talk-de] Karte auf openstreetmap.de defekt

2014-10-24 Per discussione Wolfgang Hinsch
Am Freitag, 24. Oktober 2014, 15:18:06 schrieb Falk Zscheile:
 Am 24. Oktober 2014 15:02 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:
  Außerdem - Der Unterschied zwischen uns und kommerziellen Kartendiensten
  ist
  ja gerade der, dass es uns egal ist, wo wer wie oft sich die Karte
  ansieht.
  Bei uns wird da gemappt, wo der Mapper hinfällt (vor Ort ist/Lust
  hat/Luftbilder gut sind/...). Auf sehr lange Sicht ist unser Ziel (aus
  meiner
  Sicht) eine einigermaßen gleichmäßige Erfassung weltweit, im Gegensatz zum
  kommerziellen Anbieter, der sich die Frage stellen _muss_, wie weit
  aufgelöst
  die Karte wo angeboten werden sollte. Bei OSM wird das letzte Wigwam der
  Mohikaner - falls ein Mapper vorbeikommt - mit der gleichen Sorgfalt und
  Akribie aufgenommen wie der Times Square in New York.
  
  
 Aber auch wir haben es mit knappen Ressourcen zu tun (z.B.
 Rechenkapazität). Man könnte also z.B. Regionen identifizieren, wo man
 einen höhere Auflösungen rendert ...

Wobei wir wieder beim Anbieter von Karten sind, nicht bei OSM. Wir schaffen 
eine Geodatenbank. Das Rendern ist nicht Sache von OSM, sondern eine von 
vielen möglichen Anwendungen.

Unsere Karte auf der Hauptseite, en wie de, ist vor allem eine 
Motivationsstütze für die Mapper und nur ganz, ganz nebenbei und unter engen 
Voraussetzungen ein Angebot für die Öffentlichkeit. 

Insofern ist es auch logisch und folgerichtig, dass ein Unternehmen wie Mapbox 
als Datennutzer sich fragt, wo am meisten Nachfrage besteht. 
Überraschenderweise da, wo die meisten Leute in einer einigermaßen 
durchtechnisierten Umgebung leben. Das hätte man auch mit dem Finger im Wind 
erraten können, aber jetzt ist es eben amtlich.

So ähnlich wird Geld mit Verkehrszählungen verbraten. Jeder weiß, dass auf der 
A8 mehr los ist als auf der Dorfstraße von 
Hinterpfaffenburgstedtwinkelstättenhofen. Aber gezählt ist es doch viel 
ordentlicher und amtlicher ;-)

Gegenden, in denen möglicherweise höher aufgelöst gerendert werden _könnte_, 
ergeben sich so durch die Datendichte. Allerdings stellt sich die Frage, ob es 
sinnvoll ist, Gebiete, die schon überproportional erfasst sind, durch weiter 
aufgelöstes Rendern noch weiter zu pushen, so dass dort irgendwann jeder 
Krümel erfasst ist, wogegen in anderen Regionen noch die Straßennamen fehlen 
(Schleswig-Holstein z.B., von Afrika gar nicht zu reden).

Gruß, Wolfgang

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


Re: [Talk-de] Karte auf openstreetmap.de defekt

2014-10-22 Per discussione Wolfgang Hinsch
Hi,

Am Mittwoch, 22. Oktober 2014, 13:48:17 schrieb Sven Geggus:
 Sven Geggus li...@fuchsschwanzdomain.de wrote:
  Ich vermute, dass das mit der kaputten Platte auf dem devserver
  zusammenhängt auf dem dieses komische iLike OSM läuft.
 
 Das wars ich hab das fürs Erste mal im Quellcode auskommentiert.
 

Von mir aus kann es auskommentiert bleiben. Wer brauchts?

Gruß, Wolfgang

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


[Talk-de] Adressenkonvertierung

2014-10-07 Per discussione Wolfgang Wienke

Hallo,
kennt jemand eine Internetseite, die Adressen in GPS-Koordinaten 
konvertiert? Es geht aber nicht nur um einzelne Adressen, sondern um 
einige Hundert.

--
   mit freundlichen Grüssen

 Wolfgang Wienke

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


Re: [Talk-de] Einladung und Call for Papers für die Kieler Open Source und Linux Tage

2014-09-16 Per discussione Wolfgang Hinsch
Hallo,
nochmal zur Erinnerung:

Wir möchten das OSM-Projekt einladen, bei den Kieler Open Source und
Linux Tagen, einem mittelgroßen Linux-Event in Kiel, mitzumachen.

Hier die Details:

Datum: 
19. September 2014, ca. 8 - 18 Uhr 
20. September 2014, ca. 10 - 18 Uhr 
(20.9. ist SFD)
Ort: Kieler Innovations- und Technologiezentrum (KiTZ), neben der
Christian-Albrechts-Universität

Am Donnerstag, 15. Mai 2014, 16:42:14 schrieb Wolfgang Hinsch:
 Hallo,
 
 ich habe einen OSM-Stand eingetragen.
 
 Wiki-Seite: https://wiki.openstreetmap.org/wiki/KielerLinuxTage
 
 Mitstreiter willkommen!
 
 Gruß, Wolfgang
 


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


Re: [Talk-us] Dirt Roads (formerly: Abandoned railway)

2014-09-01 Per discussione Wolfgang Zenker
Hi,

* Mike N nice...@att.net [140901 14:45]:
 On 9/1/2014 7:53 AM, Richard Fairhurst wrote:
 I think the other half of the equation, however, is actually getting this
 fixed across the country. At present it appears to be just a small number of
 mappers doing it in their areas;

To be honest, I don't really get the problem with excessive 
 'residential', or what I'd do to fix it.   If I had to study the roads 
 where I live, a few would be upgraded to tertiary or changed to 
 unclassified, and all unnamed residential would be changed to driveway, 
 but the end result would have very few changes (with the exception of 
 unnamed residential - which could be done with a bot).

I guess you haven't done much in the rural parts of the US yet. Have a
look at Lincoln County MT: You will find A LOT of tracks. Most of these
had been tagged as residential highway in the TIGER import (with horrible
distorted geometry of course), and no way could this have been fixed with
a bot. Took me about two years to get this county into the current state.

Wolfgang
(your friendly German Guest Mapper :-)

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


Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung

2014-06-03 Per discussione Wolfgang Hinsch
Am Dienstag, den 03.06.2014, 13:39 +0200 schrieb Martin Koppenhoefer:
 Am 3. Juni 2014 11:30 schrieb Falk Zscheile falk.zsche...@gmail.com:
 
  Ich denke, jetzt hat jeder Interessierte genug Argumente, um sich
  zwischen permessive und yes zu entscheiden, also zwischen quasi
  öffentlichem Raum und privatrechtlich gewährtem Zugang zu wählen.
 
 
 kurz möchte ich hier doch noch zu bedenken geben, dass yes nicht quasi
 öffentlich bedeutet, sondern dass es bedeutet, dass der Zugang öffentlich
 rechtlich gesichert ist. Permissive bedeutet ja, dass man Zugang bekommt,
 nur eben nicht, dass man auch ein sicheres Anrecht darauf hat.
 
  Bei den Aussagen und Folgerungen aus dem BVerfG-Urteil werden wir uns
  wohl nicht einig werden
 
 
 Jein, ich finde das Urteil persönlich ja durchaus begrüßenswert, nur deckt
 sich das nicht mit meiner persönlichen Erfahrung der gelebten Realität. Was
 soll man denn tun, wenn man trotz des Urteils rausgeworfen wird, ggf. von
 der Polizei, die gerufen wurde, weil man der Aufforderung zu gehen nicht
 nachkam, bzw. wenn man gar nicht erst eingelassen wird, und physisch vom
 Wachpersonal am Zugang gehindert wird? Ein Hinweis auf das BVerf.G. Urteil
 wird da doch nur mit Unverständnis quittiert werden. Selbst wenn man auf
 Zugang klagen würde und sogar Recht bekäme, dann wäre dieses Recht für
 den konkreten Fall doch nichts mehr wert, weil seitdem Monate und Jahre
 vergangen sind.

Wie immer ein Problem zwischen Recht haben und Recht bekommen,
zusätzlich möglicherweise noch ein Beweisproblem, wenn die Wachleute
irgendetwas behaupten. Das sollte man aber nicht mit der Rechtslage
vermengen, sonst mappen wir gute, mittlere und böse
Einkaufszentren, eventuell noch nach den Dienstplänen der jeweils
Verantwortlichen ;-)

access versucht, die gesetzlichen Zugangsbestimmungen für Wege
abzubilden (Zitat dt. Wiki)

Möglicherweise fehlt noch ein tag zwischen 
- permissive (jemand erlaubt den Zutritt in der Regel, ggf. während der
Öffnungszeiten, könnte ihn aber verweigern) und 
- yes (jeder hat das Recht, dort zu sein, was aber letztlich auch
Grenzen hat, siehe Sondernutzung)
 
- obligatory_tolerance (Duldungspflicht, es besteht ein Recht, sich
dort aufzuhalten, ggf. innerhalb von Öffnungszeiten, es ist aber nicht
so umfassend wie im Fall von yes) ?

Damit bekäme man auch Wege in den Griff, die sich zwar im Privateigentum
befinden, dennoch aber für den öffentlichen Verkehr freigegeben sein
müssen.

Gruß, Wolfgang


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


Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung

2014-06-02 Per discussione Wolfgang Hinsch
Hallo,
Am Montag, den 02.06.2014, 10:15 +0200 schrieb Bernd Wurst:
 Hallo.
 
 Am 02.06.2014 08:41, schrieb Falk Zscheile:
  Die Regeln sind jedenfalls deutlich eher die eines privaten Hofs als die
   eines oeffentlichen Raumes / Strasse.
  Mit solch einer Aussage wäre ich in Deutschland vorsichtig. Seit dem
  Fraport Urteil des Bundesverfassungsgerichts[1] reicht es nicht mehr,
  dass ein Einkaufszenrum o. ä. in privater Hand ist um nach Belieben
  Dritte vom Zugang auszuschließen. 
  Jedenfalls wenn diese Dritte ihre
  Grundrechte auf Meinungsäußerungs- und Versammlungsfreiheit dort
  ausüben wollen. Wie es in Italien ist, das weiß ich nicht. Jedenfalls
  sind mit dieser Entscheidung deutlich in Richtung öffentlichen Raum
  gerückt worden. Ich weiß, dass man access=Grundrechtsausübung nicht
  mappen kann, aber den Vergleich Bauernhof--Einkaufszentrum wollte ich
  dann doch hier nicht so stehen lassen.
 
 Das Urteil stützt sich maßgeblich auf den Fakt, dass die Fraport AG zu
 über der Hälfte in Besitz der öffentlichen Hand ist:
 Von der öffentlichen Hand beherrschte gemischtwirtschaftliche
 Unternehmen unterliegen ebenso wie im Alleineigentum des Staates
 stehende öffentliche Unternehmen, die in den Formen des Privatrechts
 organisiert sind, einer unmittelbaren Grundrechtsbindung. (46)

Ja, aber erweitert auf z.B. Einkaufszentren in Randnummer 68 ff. und
noch stärker 98 ff.

 
 In der abweichenden Meinung eines Verfassungsrichters (111 ff) findet
 sich ja grade die Einschätzung, dass bei Betrachtung der Einzelanteile
 jeder öffentliche Anteilseigner nur Minderheitsbeteiligter ist und daher
 das Urteil hätte anders lauten müssen. Typische Einkaufzentren befinden
 sich nicht (überwiegend) in Besitz öffentlicher Anteilseigner sondern
 sind wirklich private Betriebe. Daher lässt sich dieses BVerfG-Urteil
 hier sicherlich nicht übertragen.

Es ist ausdrücklich nicht dafür entschieden, aber u.a. in den
Randnummern s.o. gibt die ganz erhebliche Mehrheit (7:1) der Richter
hier einen deutlichen Hinweis, dass sie diese Bereiche dem freien
Himmel gleichstellt.

 
 Die Ausgangslage ist also anders und IMHO doch eher mit einem Hof zu
 vergleichen. 
-1

 Dass Einkaufszentren ihren Teil zur öffentlichen
 Infrastruktur (Grundversorgung) beitragen und daher nicht nach Belieben
 Leute vom Einkauf in den Geschäften ausschließen können halte ich zwar
 für richtig, aber die Zeiten zu denen geöffnet ist kann der Inhaber
 durchaus verändern. Er kann ja auch von heut auf morgen einfach zumachen
 wenn der Hauptmieter pleite ist.
+1

 
 Ich gehe zumindest davon aus, dass mit nach Gutdünken verweigert werden
 kann nicht unbedingt die individuelle Gesichtskontrolle gemeint ist
 sondern die Tore nach Belieben auch mal geschlossen bleiben können wenn
 der Eigentümer das so will. Oder sich die Öffnungszeiten verschieben
 können. Das Recht, diese Fläche zu nutzen, insbesondere als
 Durchgangsweg, ist nicht öffentlich vorgegeben sondern ist abhängig von
 dem Willen des Eigentümers, dass da jetzt grade jemand laufen können
 soll. Er könnte das auch baulich so umgestalten dass ein direktes
 Durchgehen unattraktiv wird.

Bezüglich der Öffnungszeiten +1

Der Betreiber hat sicherlich das Recht, zu entscheiden, wann er seine
Flächen allgemein zugänglich machen will. Er wird aber sicher nicht
sagen können, Oh nein, da kommt schon wieder X, wir schließen jetzt mal
spontan. Selbst dann, wenn X nicht einkaufen, sondern Flugblätter mit
seiner Meinung verteilen will. Insofern ein sehr interessantes Urteil.

:-)

Allerdings wird es jetzt ziemlich OT.

Gruß, Wolfgang



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


Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung

2014-06-01 Per discussione Wolfgang Hinsch
Am Sonntag, den 01.06.2014, 22:27 +0200 schrieb Christian H. Bruhn:
 am Donnerstag, 29. Mai 2014 um 13:59 schrieb Bernhard Weiskopf:
 
  Die zeitliche Zutrittsbeschränkung möchte ich in OSM erfassen, damit
  Navigationsgeräte nur zu den Öffnungszeiten hier durchleiten.
 
 Du kannst es gerne eintragen, aber bitte gehe nicht davon aus, das es
 auch nur ein Routingprogramm gibt, welches diese Angabe nutzt.

Das sollte beim Mappen auch nicht das Kriterium sein. Wenn man kein Ei
mappt, kann es auch keine Henne geben - oder so ähnlich ;-)

Gruß, Wolfgang


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


Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung

2014-05-30 Per discussione Wolfgang Hinsch
Hallo

Am Freitag, den 30.05.2014, 01:59 +0200 schrieb Martin Koppenhoefer:
 
  Am 29/mag/2014 um 22:55 schrieb Bernhard Weiskopf bweisk...@gmx.de:
  
  Da bei geschlossener Tür niemand und bei offener Tür theoretisch auch andere
  reinkommen, verwende ich für access die allgemeine Form, hier also:
  
  access = no
  access:conditional = yes @ (Mo-Sa 07:00-20:30; PH off)
  barrier = gate
  foot = yes
 
 
 bei einem Einkaufszentrum würde ich statt yes lieber permissive verwenden, 
 weil der Zugang auf Privatgelände normalerweise nicht rechtlich gesichert ist 
 sondern nach Gutdünken verweigert werden kann.

Ich bin mir da nicht so ganz sicher. Das Verweigern nach Gutdünken
könnte diskriminierend sein.

Bei einem Einkaufszentrum gelten andere Regeln als in Wohnzimmer ;-)

Gruß, Wolfgang


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


Re: [Talk-de] Rettet die Kleingarten-Wegenamen

2014-05-19 Per discussione Wolfgang Hinsch
Am Montag, den 19.05.2014, 05:50 +0200 schrieb Bernd Wurst:
 Hallo.
 
 Am 19.05.2014 02:14, schrieb Wolfgang Hinsch:
  Der Auswerter für die Navigation kann nur alle Wege im
  Kleingarten rausschmeißen oder mit mit einem Auswahlmenü für 20 Wege
  kommen, weil die Blumennamen so gerne vergeben werden. Deinen
  offiziellen Wegnamen im Kleingarten findet in beiden Fällen kaum einer.
 
 Wenn du es algorithmisch schaffst, die Wege im Kleingarten zu
 identifizieren und gezielt aus dem Suchindex rauszuschmeißen, dann
 sollte es auch gehen die Straßennamen um die Angabe der
 Kleingartenanlage zu erweitern (Rosenstraße, Kleingartenanlage XY).
 Und schon hast du den Nachteil zu einem echten Vorteil gewandelt.
 
 Grade die Kleingartensiedlungen die groß genug für Straßennamen sind,
 haben durchaus auch mal mehrere Eingänge und damit macht es Sinn, gleich
 das richtige Ziel anzusteuern.

Darin sehe ich nicht das Problem. Das Problem besteht darin, dass 
1. private Wegebezeichnungen auch außerhalb von Kleingärten auftreten
können und
2. aus den Daten nicht erkennbar/berechenbar/herleitbar ist, ob der Weg,
der sich in dem Park oder der Kleingartenanlage oder wasauchimmer
befindet, nun einen offiziellen Namen hat oder nicht. Denn auch in
Kleingartenanlagen gibt es stellenweise offizielle Wegebezeichnungen.

Praktische Folge: Der (z.B.) Taxifahrer bekommt entweder eine Hasskappe,
weil er den Namen in seinem OSM-Navi nicht findet, oder weil er den
Namen 10x findet. Im Falle des offiziellen Namens im Kleingartengebiet
mit Zusatz Kglv xx, nicht unterscheidbar von den wirklich lokalen
Kleingartennamen. In beiden Fällen wird er OSM entsorgen.

Ich bin schon konkret darauf angesprochen worden, dass die Daten für
eine professionelle Adresssuche unbrauchbar sind.

Das ist offensichtlich von der Mehrheit bei OSM so gewollt.

Die Straßenlistenauswertung ist übrigens auch recht spaßig, wenn die
Verwaltung 132 Straßennamen kennt, die bei OSM fehlen und in OSM 621
Namen sind, die der Verwaltung fehlen. Ca. 90% dürften Kleingartennamen
sein, der Rest falsche Schreibweisen, ein Bruchteil Fehler der
Verwaltung oder von OSM.

Vielleicht könnte man wenigstens aus der Straßenlistenauswertung alle
Namen in Kleingartengebieten rausschmeißen, dann kann man wieder
vernünftig manuell vergleichen.

Gruß, Wolfgang


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


Re: [Talk-de] Privat oder nicht von der öffentlichen Verwaltung benannte Wege, was: Wegenamen in Kleingärten

2014-05-19 Per discussione Wolfgang Hinsch
Am Montag, den 19.05.2014, 09:37 +0200 schrieb Falk Zscheile:


 
 Als Lösung schlagen einige hier vor das vorhandene Tagginschema so zu
 nutzen, dass Irrtümer weitgehend ausgeschlossen werden, insbesondere
 auf der Auswertungsseite zu schauen, ob man dort nicht etwas
 verbessern kann, bevor man daran geht zu sagen name bedeutet etwas
 anderes als name

Wie gesagt, den offiziellen Namen im Kleingartengelände kann keine
Auswertung vom Phantasienamen unterscheiden. Und es gibt auch in anderen
Zusammenhängen privat benannte Wege.

 
 Wenn es wirklich keine Lösung auf der Auswertungsseite gibt, dann
 könnte ich mir auch vorstellen, dass man für nicht amtlich
 registrierte Wege ein name=value und ein official_name=nonexistent
 vergibt, obwohl das auch gegen die OSM-Konvention ist und bei den
 Kartenrenderern vielleicht zu Problemen führt. Es handelt sich bei
 nonexistent ja schließlich nicht um einen echten Namen, sondern um
 eine technische Interpretationsregel.

 Jedenfalls würde ich mich über mehr Beiträge freuen, die über Lösungen
 nachdenken, die nicht die Inhaltsdefinition von name=value berühren.

Oder anders ausgedrückt, mit Zusatztags beschreiben, was name=value
definiert, damit die Mapnik-Karte nicht berührt wird. Obwohl man auch
loc_name rendern könnte, wenn name fehlt. ;-)

Ich vermute mal, dass das für die meisten der Hauptgrund ist.

official_name ist vergeben und sollte nicht umdefiniert werden.

loc_name statt name passt IMO, soll aber nicht benutzt werden.

source:name=inofficial?
name_operator=local?

Gruß, Wolfgang



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


Re: [Talk-de] Privat oder nicht von der öffentlichen Verwaltung benannte Wege, was: Wegenamen in Kleingärten

2014-05-19 Per discussione Wolfgang Hinsch
Am Montag, den 19.05.2014, 15:30 +0200 schrieb Martin Koppenhoefer:

 
 Es gibt auch privat benannte Wege, wo dieser Name amtlich und offiziell
 ist, bsp. Inge-Beisheim-Platz in Berlin (super zentral gelegen):
 http://www.openstreetmap.org/?mlat=52.51067mlon=13.37574#map=19/52.51067/13.37574
 
 http://de.wikipedia.org/wiki/Otto_Beisheim
 
 Hintergrund:
 http://www.berlin.de/ba-mitte/bezirk/gedenken/inge_beisheim.html



 
 Da kann sich jeder selbst eine Meinung bilden, nur weil die Kleingärtner
 weniger Geld haben, und deren Namen daher nicht offiziell werden würde ich
 die nicht gleich abwerten ;-)

Stop! Ich will keine Kleingärtner oder ihre Straßennamen abwerten, ich
möchte nur unterscheiden können zwischen ist amtlich oder ist nicht
amtlich. U.a. weil ist amtlich meistens, wenn auch nicht immer ist
eindeutig in der Administration, in (fast) jedem Fall aber ist in der
Liste der Administration.

Wer es für wichtig hält, kann ja taggen, ob der Name privat vergeben und
amtlich anerkannt oder amtlich vergeben und privat anerkannt wurde ;-)

Gruß, Wolfgang




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


[Talk-de] Wegenamen in Kleingärten

2014-05-18 Per discussione Wolfgang Hinsch
Hallo,

in vielen Kleingartenanlagen vergeben die Kleingärtner Wegenamen nach
eigenem Ermessen. Das führt dann dazu, dass z.B. der Dahlienweg in HH
10x oder öfter existiert, davon aber nur 1x offiziell von der Stadt
benannt und in öffentlichen Verzeichnissen vorhanden.

Wenn das Tag name für diese Wege benutzt wird, macht das die Navigation
nach OSM-Daten unbrauchbar, für jeden Navi-Benutzer wie für
Rettungsdienste, Taxi etc.

Ich würde vorschlagen, in Fällen, in denen der Name nicht offiziell ist
(es gibt auch offizielle Namen), das Tag loc_name zu benutzen, da der
Namen nur lokal im Bereich der jeweiligen Gartenanlage gilt. Name sollte
dann nicht vergeben werden.

Gegenargument der meisten Mapper dürfte sein: Dann steht der Name aber
nicht in der Karte. 

Das ist einerseits Mapping für den Renderer versus Mapping für den
Router, andererseits On The Ground steht der Name dran, aber er ist On
The Ground ebenfalls nur gültig im lokalen Bereich, nicht etwa
gemeindeweit.

Vielleicht könnte man durch ein Ticket erreichen, dass bei fehlendem
Name-Tag an Verkehrswegen auf ein loc_name-Tag geprüft und dieses in
Z17-19 angezeigt wird.

Meinungen?


Gruß, Wolfgang


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


Re: [Talk-de] Rettet die Kleingarten-Wegenamen

2014-05-18 Per discussione Wolfgang Hinsch
Am Sonntag, den 18.05.2014, 21:45 +0200 schrieb Jan Tappenbeck:
 Hallo Wolfgang,
 
 ich weiß einfach nicht, warum Du immer wieder gegen die Namen in den 
 Kleingärten bist. Wenn es Dich für Deine Karten stört, dann rechne diese 
 doch mit einer Datenbankfunktion raus

Blödsinn. Du solltest eigentlich wissen, dass ich das auch ohne deinen
Rat machen würde, wenn es mir darum ginge.

Ich bin nicht gegen Namen in Kleingärten, sondern will nur die
Phantasienamen örtlicher Kleingärtner (und Vergüngungsparks etc.)
eindeutiger von den offiziellen Namen unterscheiden können. Im Moment
sieht es so aus, dass in Aufbereitungen für das Routing alle Namen
innerhalb Kleingärten entweder rausgeschmissen werden müssen, egal ob
sie offiziell sind oder nicht, oder es kommt zu umfangreichen
Auswahllisten. Wenn die Kleingärten die gleiche PLZ haben, hilft auch
eine Auswahlliste nicht weiter, kennt man die PLZ nicht, ist man
aufgeschmissen. Ein Taxifahrer schmeißt nach so einer Erfahrung
OSM-Karten sofort über Bord. Das halte ich für unbefriedigend.


 Solange nicht anderer Missbrauch des Namen-Tags bereinigt ist sollten 
 man sich an den Laubenpiebern nicht vergreifen.
??

  Möchte nur die Benennung 
 der Bushaltestellen am Hamburger ZOB anführen. Die ersten 10-20 Straßen 
 in alphabetischer Reihenfolge für HH sind die Haltestellen dort.

Wenn es dich stört (und falsch ist), ändere es. Nicht meine Baustelle.
Und OT.

 
 Die Frage nach der Benennung der offiziellen Straßennamen ist wer diese 
 durchführt. Bei städtischen Straßen ist das zwangsläufig die öffentliche 
 Verwaltung. Wie ich schon in dem Posting im Forum geschrieben habe 
 (http://forum.openstreetmap.org/viewtopic.php?id=22750 - hier ging es 
 mal wieder um die KLG-Parzellennummern die einige stört und nun 
 gnadenlos auf die schnelle und ohne offizielle Abstimmung umgestellt 
 wurden. Wo sind die Wächter über die Tags und Massenedits??) gibt es in 
 der offiziellen Liste der Hansestadt Lübeck Wege in den Kleingärten 
 (Beispiel Parade 1-7 u.a.http://www.openstreetmap.org/?way=35050005) die 
 ich nur durch Zufall in einem Kleingartengelände gefunden habe.

Genau. Der Auswerter für die Navigation kann nur alle Wege im
Kleingarten rausschmeißen oder mit mit einem Auswahlmenü für 20 Wege
kommen, weil die Blumennamen so gerne vergeben werden. Deinen
offiziellen Wegnamen im Kleingarten findet in beiden Fällen kaum einer.

 
 Was ist mit den Wegen im Forst und im Feld - denen kann ich nicht 
 ansehen, ob diese offiziell sind und dennoch schreibe ich diese in OSM 
 rein. Genauso verhält es sich mit den Klg-Namen.

Auf den ersten Blick kannst du es nicht sehen, richtig. Schreib ihn
ruhig rein. Wenn weitere Erhebungen ergeben, dass er nicht offiziell
ist, kann er immer noch auf ein passenderes *_name-tag verschoben
werden.


Ich könnte übrigens auf meinem Grundstück meine Wege mit
Mönckebergstraße, Heidenkampsweg oder ähnlichem benennen, einen
Pfahl reinrammen und mit einem Holzschild beschriften. Anschließend On
The Ground mappen. Viel Spaß.

Was machen wir eigentlich, wenn tatsächlich irgendwelche Spaßvögel auf
so eine Idee kommen? Das klingt jetzt vielleicht unwahrscheinlich, aber
dem einen oder anderen Oberförster würde ich so was schon zutrauen.

 
 Wenn es einem um die Mehrfachnennung von Namen geht, dann gibt es 
 sicherlich auch Orte, entstanden aus Zusammenlegungen, wo die Dorfstraße 
 mehrfach vorkommt.

Ich weiß, dass in Meck-Pomm wegen einer Zusammenlegung von Gemeinden
ganz genau die Dorfstraße umbenannt wurde, um doppelte Straßennamen zu
vermeiden. In einigen Ländern ist das sogar im Gesetz so vorgesehen, lt.
entspr. Postings hier. Ob das im Meck-Pomm gesetzlich erzwungen wird,
entzieht sich meiner Kenntnis. Vernünftig ist es auf jeden Fall.

 
 Auf der anderen Seite ist OSM doch ein Projekt das für die breite Masse 
 und will sich von den anderen abheben.

Genau. Im Moment hebt es sich dadurch von anderen ab, dass ich mit
meinem Nüvi mit der Garmin-Karte eine Rosenstraße in Hamburg finde. Mit
der OSM-Karte finde ich mit demselben Gerät 9 verschiedene Rosenstraßen.
Ein echtes Alleinstellungsmerkmal. Jetzt frage mal, warum kein
Autohersteller OSM-Karten in sein Navi einbaut.

  Jeder hat andere Interessen - den 
 einen interessieren die Wege und den anderen die anderen. Bei einem 
 Besuch bei den Kleingärtnern war man begeistert das mal einer die Wege 
 alle erfaßt hat.

Wieder nicht zuende gedacht. Mapnik könnte bei fehlendem name-Tag auf
das nächstliegende ausweichen.

  Ich finde es schon sch... genug das durch den o.g. 
 Massenedit plötzlich all die mühsam erfaßten Parzellennummern 
 rausradiert wurden. Das steht noch auf einem anderen Blatt und wird bei 
 uns Thema auf dem nächsten Stammtisch sein..
 

eben, anderes Blatt.

 Also Rettet die Kleingarten-Wegenamen

Unsinn, die will niemand rausschmeißen. Oder sollte sich das nur auf
Mapnik beziehen (für den Renderer... ?)

Die Mehrheit bei OSM geht im Moment den Weg, das Name-Tag zu verwenden.
Die

Re: [Talk-de] Wegenamen in Kleingärten

2014-05-18 Per discussione Wolfgang Hinsch
Am Sonntag, den 18.05.2014, 22:03 +0200 schrieb Mark Obrembalski:
 On 18.05.2014 21:17, Johannes wrote:
  Sehe ich genauso. Wenn etwas keinen amtlichen Namen hat gehört es
  in loc_name rein und name entfernt.
 
 Quatsch! Kein Laden, keine Kneipe hat einen amtlichen Namen. 

Dann mach mal einen Laden ode eine Kneipe auf. Du wirst dich wundern, in
wie viele Verzeichnisse, Anmeldungen, Lizenzen, Genehmigungen ... du den
Namen eintragen musst. Und zwar immer denselben. Aussuchen darfst du ihn
dir selbst, ja. Aber anschließend ist er deine Firma. Kannst du
jederzeit ändern. Aber du wirst dich wundern, in wie viele
Verzeichnisse ... ;-)

Gruß, Wolfgang


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


Re: [Talk-de] Rettet die Kleingarten-Wegenamen

2014-05-18 Per discussione Wolfgang Hinsch
Hi, ps:
 Am Sonntag, den 18.05.2014, 21:45 +0200 schrieb Jan Tappenbeck:

   Ich finde es schon sch... genug das durch den o.g. 
  Massenedit plötzlich all die mühsam erfaßten Parzellennummern 
  rausradiert wurden. Das steht noch auf einem anderen Blatt und wird bei 
  uns Thema auf dem nächsten Stammtisch sein..
  

:1,$ s/rausradiert/auf das ref-Tag verschoben/g

Rausradiert wurden sie aus der Mapnik-Karte, nicht aus den Daten.

In Hamburg hat jemand in Alsternähe sämtliche landuse=residential
rausradiert. Aus den Daten rausvandaliert, nicht verschoben. Weil sie
eine Zeit lang in der Mapnik-Darstellung Vorrang vor seinem
leisure=garden hatten.

War ihm nicht grün genug.

Das Argument ist im Grunde das Gleiche.

Manchmal würde ich die Mapnik-Karte am liebsten ganz abschalten...
;-)

Gruß, Wolfgang


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


Re: [Talk-de] Einladung und Call for Papers für die Kieler Open Source und Linux Tage

2014-05-15 Per discussione Wolfgang Hinsch
Hallo,

Am Dienstag, den 13.05.2014, 15:54 +0200 schrieb Michael Reichert:
 Hallo,
 
 das kam gerade bei uns vom Wochennotizteam. Wer möchte sicv drum kümmern.

ich habe einen OSM-Stand eingetragen.

Wiki-Seite: https://wiki.openstreetmap.org/wiki/KielerLinuxTage

Mitstreiter willkommen!

Gruß, Wolfgang


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


Re: [Talk-us] Sidewalks as footpaths

2014-04-30 Per discussione Wolfgang Zenker
* Mike N nice...@att.net [140430 18:21]:
 On 4/30/2014 11:38 AM, William Morris wrote:
 Is there a general OSM policy on marking sidewalks as highway=footway?
 User dolphinling appears to have gone crazy in downtown Burlington,VT
 tracing the sidewalks and calling them footways.

It does add a great deal of clutter to those maps that render 
 footways.   But for those who wish to be able to use OSM data for 
 accurate pedestrian or handicapped routing, the only way is to draw all 
 the sidewalks, curb cuts, and pedestrian crossings.

AFAICS there are basically two ways in use to get information on sidewalks
into OSM:
- map sidewalks as separate ways
- use http://wiki.openstreetmap.org/wiki/Key:sidewalk to add information
  on sidewalks to the main highway.

Both methods should be usable for pedestrian routing; using separate
ways allows for more detailed micro-mapping, e.g. width and paving of
the sidewalk, but is a lot more difficult to get it right because you
need to connect these ways with the main highway everywhere a pedestrian
could cross the highway.

Wolfgang

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


Re: [Talk-de] maxheight=none

2014-03-31 Per discussione Wolfgang Hinsch
Am Montag, den 31.03.2014, 09:58 +0200 schrieb Martin Koppenhoefer:
 Am 31. März 2014 09:50 schrieb Florian Lohoff f...@zz.de:
 
  Auf Straßen an denen keine Brücke drüber ist gehört IMHO nix dran.

 es sind nicht nur Brücken, die ggf. das zur Verfügung stehende
 Lichtraumprofil einschränken, z.B. Allee-Bäume, Straßenbahnoberleitungen
 und Beleuchtungskörper / Ampeln und Schilderbrücken können Hindernisse
 darstellen.
 

Es sollte eine Obergrenze geben für maxheight, z.B. 4,50.
Sondertransporte fahren sowieso nicht nach OSM, auch nicht nach
irgendwelchen anderen Quellen, sondern erkunden die Strecke zeitnah
selbst. Es gibt sonst zu viele Überraschungen durch provisorische
Brücken, Leitungsüberführungen etc. pp., wo der Transport hängen bleiben
könnte.

Übrigens sind Sondertransporte oft nicht nur extrem hoch, sondern auch
extrem breit oder lang. Für die Breite könnte man notfalls noch mappen,
aber wie wollen wir ermitteln, mit welcher Länge man da noch rumkommen
könnte bzw. welchen Balkon man abbauen müsste? ;-)

Gruß, Wolfgang


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


Re: [Talk-de] Noch eine Wappenkarte

2014-03-29 Per discussione Wolfgang Hinsch
Hallo Tim,

Am Samstag, den 29.03.2014, 15:05 +0100 schrieb Kolossos:
 Hallo, das Berliner Hackweekend hatte ich mal genutzt die Idee der
 Wappenkarte auf Wikidata-Basis aufzugreifen und in meine
 Koordinatenextraktion der Wikipedia zu integrieren:
 http://toolserver.org/~kolossos/openlayers/kml-on-ol.php?lang=deuselang=dezoom=6lat=50.08584lon=6.63143coats=yes
 
 Das sind jetzt 42.000 Wappen bei 3.5 Mio Artikeln, viel Spaß beim stöbern.

ich würde vorschlagen, dass ihr euch mal überlegt, wie man möglichst
einfach melden kann, dass man Fehler gefunden hat. Ich finde ca. alle 20
Sekunden einen falsch verlinkten Artikel.

Es müsste da eine einfache Möglichkeit geben anzuzeigen, dass das Objekt
hier nicht ist. Häufig kennt man das Objekt gar nicht und weiß nur,
dass es jedenfalls nicht an der eingetragenen Stelle sein kann. Also
eine Meldungsmöglichkeit ohne eine Master-Arbeit in Wiki-Web-Bearbeitung
und Registrierung hier/Registrierung da etc pp.

Etwa so wie die Notes auf OSM.

Gruß, Wolfgang


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


Re: [Talk-de] Postalische Bezeichnung (addr:place -)

2014-03-29 Per discussione Wolfgang Hinsch
Hallo Andreas,

Am Freitag, den 28.03.2014, 07:00 +0100 schrieb Andreas Neumann:
 Fehler beim Überprüfen der Signatur
 Fehler bei der Syntaxanalyse --ms010607030705050801080908
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 
 Fehler beim Überprüfen der Signatur
 Hash: SHA1
 gpg: ASCII-Hülle: 
 Version: GnuPG v1.4.14 (GNU/Linux)
 gpg: ASCII-Hülle: 
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 gpg: ASCII-Hülle: 
 gpg: Ursprünglicher Dateiname=''
 gpg: Falsch aufgebaute Prüfsumme
 gpg: Keine Signatur gefunden
 gpg: quoted printable Zeichen in der ASCII-Hülle gefunden -
 möglicherweise
 war ein fehlerhafter Email-Transporter(MTA) die Ursache
 gpg: Die Signatur konnte nicht überprüft werden.
 Denken Sie daran, daß die Datei mit der Signatur (.sig oder .asc)
 als erste in der Kommandozeile stehen sollte.
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Einerseits w=E4re addr:place wohl das sinnvollere. Andererseits werten
 viele Programme nur addr:street aus und wie du es ausschreibst w=E4re
 es
 einer Stra=DFe gleichzusetzen.
 
 Jetzt ist die Frage, ob du es syntaktisch korrekt taggen willst oder
 f=FCr die Auswerter.
 
 MfG Andreas
 

so kommt deine Mail bei mir an.

(Evolution 3.2.3)

Gruß, Wolfgang


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


Re: [Talk-de] Hervorheben von POIs auf eignen Karten

2014-03-27 Per discussione Wolfgang Wienke

Am 27.03.2014 09:26, schrieb Manuel Reimer:

Wolfgang Wienke wo_wienke at gmx.net writes:

Du kannst dir via Overpass API die Koordinaten für die Pins aus dem
OSM-Datenbestand abholen. So kann man wunderbar einzelne POIs und auch
ganze Wege mit OpenLayers-Mitteln hervorheben.


Das heißt aber dann doch, dass ich die POIs wieder selbst über Pins
setzen muss!??


Wie sonst? Du holst dir die Koordinaten ab (bei einem meiner Projekte mache
ich das automatisch einmal am Tag in der Nacht via Cron-Job).

Dann bleibt es dir überlassen wie du die erhaltenen Daten nachbearbeitest.
Du könntest z.B. sowas damit füttern:

http://openlayers.org/dev/examples/dynamic-text-layer.html

Oder nach der Anleitung vorgehen:

http://wiki.openstreetmap.org/wiki/Openlayers_POI_layer_example

Grundlegende Programmierkenntnisse sind natürlich nötig um aus den OSM-Daten
das für OpenLayers nötige Eingabeformat automatisiert zu erzeugen.


Ok, danke, damit sehe ich, welcher Weg möglich wäre.


--
   mit freundlichen Grüssen

 Wolfgang Wienke

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


Re: [Talk-de] Hervorheben von POIs auf eignen Karten

2014-03-26 Per discussione Wolfgang Wienke

Am 25.03.2014 10:09, schrieb Manuel Reimer:

Wolfgang Wienke wo_wienke at gmx.net writes:

gibt es eine Möglichkeit auf eingebundenen OSM-Karten (z.B. gemäß Beisp
openlayers.org) eine bestimmte Art von POIs z.B. durch einen pushpin
automatisch hervorzuheben, OHNE jeweils solche pushpins mit Koordinaten
separat an der Position einzublenden?


Du kannst dir via Overpass API die Koordinaten für die Pins aus dem
OSM-Datenbestand abholen. So kann man wunderbar einzelne POIs und auch ganze
Wege mit OpenLayers-Mitteln hervorheben.


Das heißt aber dann doch, dass ich die POIs wieder selbst über Pins 
setzen muss!??




--
   mit freundlichen Grüssen

 Wolfgang Wienke

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


  1   2   3   4   5   6   7   8   9   10   >