Re: [Talk-de] Wohnort

2011-03-21 Thread Bernd Wurst
Am Sonntag, 20. März 2011, um 16:00:06 schrieb Christian Müller:
> meist sind sie schon konkrete Luftbild-Schätzungen von Wohngebieten, die
> einem Wanderer oder Geocacher sehr genau sagen, wo er mit höchster
> Wahrscheinlichkeit privaten Grund betritt.

Im Gegensatz zu dem ganzen Umland, das ja niemandem gehört oder wie?

Gruß, Bernd

-- 
An den Scheidewegen des Lebens stehen keine Wegweiser
  -  Charly Chaplin (engl. Filmkomiker)


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Wohnort

2011-03-21 Thread Bernd Wurst
Hallo Markus.

Am Sonntag, 20. März 2011, um 14:35:15 schrieb Markus:
> Damit haben sich so unspezifische Angaben wie "place" und "landuse" m.E. 
> erübrigt?
> Es sei denn hinter dem "landuse" verbirgt sich eine offizielle Grenze 
> (Baugebiet, Industriegebiet, Naturschutzgebiet, etc).

Im Prinzip kann man das so sehen, aber bei OSM sind wir doch in aller Regel 
pragmatisch veranlagt.

Und dazu gehört nunmal auch, dass spezifische (soweit erfasst) und 
unspezifische Angaben gemischt vorkommen können. Und ein grober Umriss ist 
leichter zu erfassen (auch mittels schlechtem Luftbild) als eintzelne Häuser 
und Straßen und ganz ehrlich: Diese schicke graue Hinterlegung von bebautem 
Gebiet ist einfach das was man von einer Landkarte so kennt und auch erwartet. 
Die algorithmisch zu bestimmen ist nicht so einfach. 

Daher der pragmatische Weg, grober Umriss der bebauten Fläche damit man auf 
der Karte auf einen Blick z.B. erkennen kann wie groß ein Ort ist.

Wenn du ein zuverlässiges Verfahren vorstellst, wie man, basierend auf 
diversen anderen Daten, diese Fläche berechnen kann, dann kann man die aus den 
Daten weg lassen. Aber das halte ich für sehr kompliziert.

Gruß, Bernd

-- 
Die Gehirnwäsche gilt allenthalben als fürchterlich und schrecklich. Es gibt 
aber Gehirne, denen eine Wäsche ganz gut täte.  -  Johannes Gross (dt. 
Publizist 1932)


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Relationen "Landmasse"

2011-03-21 Thread M∡rtin Koppenhoefer
Am 21. März 2011 02:21 schrieb Henning Scholland :
>> und dass "Landmassenrelationen redundant" sind, ist keine Meinung, sondern
>> eine Tatsache (redundant = die Information ist mehrfach vorhanden).
>
> Wie steht es dann um service=parking_aisle? Ist ja auch redundant. Ein
> highway=service innerhalb eines amenity=parking-Polygons ist doch ein
> Parkplatzweg.


nein, ist er nicht. Ein highway=service über einen Parkplatz kann z.B.
auch eine Zufahrt oder sonst ein Weg sein, der streckenweise über
einen Parkplatz führt.


> Ebenso das einzeichnen von Bahnübergängen und Furten...


Das sind beides Dinge, die man in einer perfekten Karte nicht
unbedingt bräuchte, stimmt. Wenn man aber von tausenden
unvorbelasteten Laien eine Karte zeichnen lässt ist es nicht schlecht,
solche Stellen explizit anzugeben, und sie damit von Brücken und
Tunneln klar unterscheidbar zu machen, die oft vergessen werden.

Wobei so ein einzelner Node m.E. überhaupt nicht mit einer Relation zu
vergleichen ist, die unzählige Mitglieder hat, und zwangsläufig die
History belastet, ohne dass sie einen Sinn ergibt (könntest Du es mir
evtl. erklären, was die aktuellen Anwendungsfälle der
Landmasse-Relationen sind, die es vorteilhaft erscheinen lassen, die
Information absichtlich doppelt einzutragen - muss ja dann auch
doppelt gepflegt werden ?).


Gruß Martin

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


[Talk-de] Hilfestellung für Windows-Batch und osmosis

2011-03-21 Thread Jan Tappenbeck



 hi !

ich habe mir ein Batchgebastelt mit welchem ich Daten aus 
osmosis-Filtern will (node und ways) um diese dann in einer Datei 
zusammenzuführen.


Hierzu verwende ich folgenden Ausdruck in einem Batch-File:

rem osmworkfolder  Verzeichnis für den Osmosiszugriff
set project=hot_japan
set 
selectionset=amenity.pharmacy,amenity.hospital,amenity.school,amenity.college,amenity.university,amenity.fire_station,amenity.police,amenity.shelter,amenity.telephone,shop.supermarket,amenity.nursing_home 



%osmworkfolder%\osmosis\bin\osmosis.bat -v 99 --read-pbf latest.osm.pbf  
--tee 2 --node-key-value keyValueList=%selectionset% --write-xml 
%project%_node.osm --way-key-value keyValueList=%selectionset% 
--used-node --write-xml  %project%_way.osm


%osmworkfolder%\osmosis\bin\osmosis.bat --read-xml %project%_node.osm  
--read-xml %project%_way.osm --merge --write-xml %project%_select.osm


Das Filtern funktioniert auch - aber dann bricht das Script ab ohne eine 
Meldung. Auch beim Start über das CMD-Fenster kommt keine Fehlermeldung. 
Das Protokoll der Filterung habe ich unten angehängt.


Der Merge-Prozess wird nicht ausgeführt mehr - wenn ich den alleine 
ausführe dann ist werden die beiden Dateien verschmolzen.


Kann mir einer von Euch weiterhelfen ??

Gruß Jan :-)

D:\DATEN\JAN\openstreetmap\HOT_Auswertung>D:\DATEN\JAN\openstreetmap\osmosis\bin
\osmosis.bat -v 99 --read-pbf latest.osm.pbf  --tee 2 --node-key-value 
keyValueL

ist=amenity.pharmacy,amenity.hospital,amenity.school,amenity.college,amenity.uni
versity,amenity.fire_station,amenity.police,amenity.shelter,amenity.telephone,sh
op.supermarket,amenity.nursing_home  --write-xml hot_japan_node.osm 
--way-key-va
lue 
keyValueList=amenity.pharmacy,amenity.hospital,amenity.school,amenity.colleg

e,amenity.university,amenity.fire_station,amenity.police,amenity.shelter,amenity
.telephone,shop.supermarket,amenity.nursing_home  --used-node 
--write-xml hot_ja

pan_way.osm
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.Osmosis run
INFO: Osmosis Version 0.38
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin configuration file from url 
jar:file:/D:/DATEN/JAN/openst

reetmap/osmosis/lib/default/osmosis-apidb-0.38.jar!/osmosis-plugins.conf.
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin via loader 
org.openstreetmap.osmosis.apidb.ApidbPluginLoa

der.
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin configuration file from url 
jar:file:/D:/DATEN/JAN/openst

reetmap/osmosis/lib/default/osmosis-areafilter-0.38.jar!/osmosis-plugins.conf.
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin via loader 
org.openstreetmap.osmosis.areafilter.AreaFilte

rPluginLoader.
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin configuration file from url 
jar:file:/D:/DATEN/JAN/openst

reetmap/osmosis/lib/default/osmosis-binary-0.38.jar!/osmosis-plugins.conf.
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin via loader crosby.binary.osmosis.BinaryPluginLoader.
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin configuration file from url 
jar:file:/D:/DATEN/JAN/openst

reetmap/osmosis/lib/default/osmosis-core-0.38.jar!/osmosis-plugins.conf.
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin via loader 
org.openstreetmap.osmosis.core.CorePluginLoade

r.
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin configuration file from url 
jar:file:/D:/DATEN/JAN/openst

reetmap/osmosis/lib/default/osmosis-dataset-0.38.jar!/osmosis-plugins.conf.
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin via loader 
org.openstreetmap.osmosis.dataset.DatasetPlugi

nLoader.
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin configuration file from url 
jar:file:/D:/DATEN/JAN/openst

reetmap/osmosis/lib/default/osmosis-pgsnapshot-0.38.jar!/osmosis-plugins.conf.
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin via loader 
org.openstreetmap.osmosis.pgsnapshot.PgSnapsho

tPluginLoader.
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin configuration file from url 
jar:file:/D:/DATEN/JAN/openst

reetmap/osmosis/lib/default/osmosis-replication-0.38.jar!/osmosis-plugins.conf.
21.03.2011 13:00:19 org.openstreetmap.osmosis.core.TaskRegistrar 
loadBuiltInPlug

ins
FEINER: Loading plugin via loader 
org.openstreetmap.osmosis.replication.Repl

Re: [Talk-de] Japan: Wie OpenStreetMapper helfen können

2011-03-21 Thread Pascal Neis

Hi,

RalfGesellensetter schrieb:


Auf der anderen Seite könnte ich mir vorstellen, dass es problematisch
wäre, zerstörte Straßenzüge einfach zu löschen, da ja z.B. die 
Information über deren Lage dabei helfen könnte, Verschüttete zu finden.


Zerstörte Straßen solltem demnach eher mit einem Tag "zerstört"
versehen werden, oder?


kennst du "Erdbeben und Tsunami in Japan" im OSM Blog ?
http://blog.openstreetmap.de/2011/03/erdbeben-und-tsunami-in-japan/


darin sind einige Informationen enthalten,
auch zum Thema "zerstörte" oder "nicht passierbare"
Straßen ...

viele gruesse
pascal

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


Re: [Talk-de] Hilfestellung für Windows-Batch und osmosis

2011-03-21 Thread NopMap
Wenn Du aus einer Batch-Datei eine Batch-Datei aufrufen willst, mußt Du das
mit "call" machen, sonst wird die aktuelle Batch durch die aufgerufene
ersetzt.

bye
Nop


--
View this message in context: 
http://gis.638310.n2.nabble.com/Hilfestellung-fur-Windows-Batch-und-osmosis-tp6191983p6192114.html
Sent from the Germany mailing list archive at Nabble.com.

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


Re: [Talk-de] Hilfestellung für Windows-Batch und osmosis

2011-03-21 Thread Jan Tappenbeck

Am 21.03.2011 13:46, schrieb NopMap:

Wenn Du aus einer Batch-Datei eine Batch-Datei aufrufen willst, mußt Du das
mit "call" machen, sonst wird die aktuelle Batch durch die aufgerufene
ersetzt.

bye
 Nop


--
View this message in context: 
http://gis.638310.n2.nabble.com/Hilfestellung-fur-Windows-Batch-und-osmosis-tp6191983p6192114.html
Sent from the Germany mailing list archive at Nabble.com.

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



ach ja, da leidige Thema - osmosis war früher ja mal kein bat und 
deshalb mache ich immer noch den fehler.


danke !

gruß Jan :-)


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


[Talk-de] Blocked Tile Scaper and Issues

2011-03-21 Thread Grant Slater
Hi Talk-de,

First apologies for my email being in English. I do not yet speak
German. Feel free to translate.

I have had to blocked the tile scaping app "Mobile Atlas Creator" from
mass downloading tiles from tile.openstreetmap.org, it was causing an
undue strain on our limited resources and effecting the tiles being
served to mappers. The app allows downloading huge areas, including
heavily scaping of z17 and z18 tiles [1]. The app was responsible for
between 7% and 30% of our traffic. This morning ~236 tiles per second.

The app uses a faked User-Agent [2] and the block may effect some
mappers in Germany. Please let me know if any problems are observed.
Faking a User-Agents is absolutely unacceptable.
http://wiki.openstreetmap.org/wiki/Tile_Usage_Policy

There has been some German discussion about this application:
http://forum.openstreetmap.org/viewtopic.php?id=10960&p=1
(I have not yet read the thread)

1: Most high zoom tiles tend to be have never been viewed and require
rendering on demand. See
http://wiki.openstreetmap.org/wiki/Tile_Disk_Usage for example viewing
percentages.
2: 
http://mobac.svn.sourceforge.net/viewvc/mobac/trunk/MOBAC/src/main/java/mobac/program/download/UserAgent.java?r1=1411&r2=1657

Regards
 Grant
 Part of the OSM Sysadmin Team

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


Re: [Talk-de] Wohnort

2011-03-21 Thread Heiko Jacobs

Am 21.03.2011 08:17, schrieb Bernd Wurst:

Im Gegensatz zu dem ganzen Umland, das ja niemandem gehört oder wie?


Ob der Pilzesammler im Wald oder im Hausgarten steht, ist rechtlich relevant ;)


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


[Talk-de] POI-Karte -> Melden wichtiger Tags ...

2011-03-21 Thread Jan Tappenbeck

Hi !

wie vielleicht der eine oder andere schon vernommen hat habe ich meine 
POI-Karte von Haiti wieder aufleben lassen.


http://www.tappenbeck.net/osm/maps/deu/index.php?id=2000

Man hat mir freundlicherweise eine Tagliste zur Verfügung gestellt und 
das sah vor einigen Tagen noch sehr mau aus.


Wenn jemand den Eindruck hat das wichte Tags verwendet wurden dann möge 
er mir diese bitte mitteilen. Wenn Ideen für Icon und Kurzbeschreibung 
dabei sind sage ich nicht nein.


Einfach das ganze HOT-Datenmodell zu übernehmen ist derzeit noch etwas 
verfehlt.


Gruß Jan :-)


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


Re: [Talk-de] Wohnort

2011-03-21 Thread Bernd Wurst
Am Montag, 21. März 2011, um 16:42:36 schrieb Heiko Jacobs:
> Ob der Pilzesammler im Wald oder im Hausgarten steht, ist rechtlich
> relevant ;)

Wald ist was anderes, darum ging es nicht.

Gruß, Bernd

-- 
Schade, daß rote Zahlen auf dem Konto nicht annähernd so beruhigend sind
wie auf dem Kalender.


signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de


Re: [Talk-de] Mobile Atlas Creator - Lizenz- und Policyverstöße

2011-03-21 Thread Frederik Ramm

Hallo,

NopMap wrote:

Ich habe mir gerade mal das Download-Tool Mobile Atlas Creator kritisch
angesehen.


Mobac ist jetzt, wie Grant vorhin ja schrieb, vom Tileserver gesperrt, 
soweit das aufgrund der gefakten User-Agents ueberhaupt moeglich ist. 
Die fehlenden Quell-/Lizenzhinweise sind dabei weniger der Grund als 
vielmehr, dass die Applikation zum Teil fuer 30% des Tile-Traffics auf 
OSM verantwortlich war; offenbar muss sie in der letzten Zeit massiv an 
Verbreitung gewonnen haben.


Der gefakte User-Agent ist dabei, wie Nop schon sagte, ein klarer 
Verstoss gegen unsere Policy (und gegen uebliche Verhaltensregeln im Web 
sowieso). Ich habe kein Statement von den Programmierern dazu; ich 
hoffe, dass sie sich schaemen.


Bye
Frederik

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


Re: [Talk-de] Relationen "Landmasse"

2011-03-21 Thread Frederik Ramm

Hi,

On Mon, 21 Mar 2011 02:21:16 +0100
> Eigentlich hab ich an allen relevanten Punkten ein "meiner Meinung 
> nach" drin, oder nicht? Dass die Erfassung unveraenderlicher,


Was ist denn schon unveränderlich und warum soll "unveränderliches" 
nichts in OSM verloren haben?


OSM ist ein Datenerfassungsprojekt und kein Sammelplatz fuer
oeffentliche Geodaten dieser Welt. Unveraenderlich ist hier gemeint im
Sinne von autoritativ - wenn die Regierung (oder ein internationales
Abkommen) festlegt, dass die Grenze hier und da verlaeuft, dann
verlaeuft sie da, und kein Mapper der Welt kann daran eine (sinnvolle)
Aenderung vornehmen. Also ist es es unsinnig, fuer sowas eine
crowdsource-Datenpflege-Engine zu benutzen.

"Was ein Mapper nicht sinnvoll bearbeiten kann, gehoert nicht in
OSM" ist bestimmt kein Spruch, den ich mir ausgedacht habe.

> unbeobachtbarer 
Nunja...da haben wir aber so einiges auch schon länger in den Daten 
drin. Fährlinien, Grenzen, teilweise ÖPNV-Routen... und wenn man

länger drüber nachdenkt, findet man sicherlich auch noch ein paar
mehr.


Das ist ganz bestimmt richtig. Einige Grenzen habe ich sogar selber
importiert, ich sehe also durchaus, dass man das nicht ganz so eng
sehen darf. Besonders dann, wenn eine Grenze oder sonst irgendwas als
Katalysator fuer weiteres Mappen diesen kann, so z.B. haben wir die
importierten Villages aus OpenGeoDB oder so, die nun leichter fuer
Analysen a la "hier fehlt noch was" bereitstehen. Es ist also in jedem
Fall eine Abwaegung. Ganz bestimmt ist es aber nicht zulaessig, zu
sagen: Wir haben eh schon viel von X, daher kann weiteres X ohne
Nachzudenken erfasst werden. Im Falle dieser unbeobachtbaren, vom
Mapper nicht sinnvoll aenderbaren Sachen ist es immer eine
Einzelfallentscheidung.


Die Grenzen sind für viele OSMer ein Mitbestandteil von OSM. Bei
Fähren und ÖPNV wäre das Raunen auch groß, wenn man sie raus kegeln
würde.


Da stimme ich zu, wobei das mit den Grenzen manchmal etwas auszuufern
scheint - wie gesagt, bloss weil wir bestimmte Grenzen haben, heisst
das nicht, dass wir *alle* wollen.

> und dass "Landmassenrelationen redundant" sind, ist keine Meinung, 
> sondern eine Tatsache (redundant = die Information ist mehrfach 
> vorhanden).



Wie steht es dann um service=parking_aisle? Ist ja auch redundant.


Ja, klar. Vielleicht verstehen wir uns da falsch; wenn ich schreibe
"ist redundant" dann meine ich nicht "kann ohne weiteres geloescht
werden". Das "redundant" ist eine ganz sachliche Feststellung. Wir
haben eine Menge reduntante Tags, z.B. auch bei den Adressen, und das
ist natuerlich aus Datenbanksicht immer doof, aber zuweilen auch
ziemlich praktisch, weil es die Fehlersuche erleichtert...

Alles was ich oben aufgezählt hab sind meiner Meinung nach Beispiele, 
die in deine Kriterien passen, aber dennoch einen Nutzen für OSM

haben. Meiner Meinung nach ist die Tatsache, dass in OSM mehr
Lage-Infos enthalten sind, als für eine Straßenkarte erforderlich,


Um die Unterscheidung Strassenkarte/andere Karte geht es dabei meistens
nicht; sondern eher um die Frage, ob wir es mit echten von uns
erfassten und aus der Vermessungstaetigkeit von Mappern entstandenen
Daten zu tun haben, oder ob jemand Koordinaten aus einer Publikation
abschreibt; letzteres ist manchmal nuetzlich, steht aber eigentlich in
keinem Bezug zu unseren sonstigen Daten und wird oft nur der
Bequemlichkeit halber in OSM gehalten. Das ist aber ein Ansatz, den man
nur ganz begrenzt verfolgen kann, es gibt heute schon weit mehr freie
Geodaten (die sicher alle fuer irgendwen nuetzlich sind) als wir in OSM
vertragen koennen. Beim Mappen setzen wir da keine Grenzen - ein Mapper
kann nur eine bestimmte Menge an Daten produzieren, und mit der werden
wir schon fertig. Bei der Frage, welche existierenden Geodaten in OSM
uebernommen werden, muss man genauer hinschauen.

Bye
Frederik

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


Re: [Talk-de] Relationen "Landmasse"

2011-03-21 Thread M∡rtin Koppenhoefer
Am 21. März 2011 19:24 schrieb Frederik Ramm :
> OSM ist ein Datenerfassungsprojekt und kein Sammelplatz fuer
> oeffentliche Geodaten dieser Welt. Unveraenderlich ist hier gemeint im
> Sinne von autoritativ - wenn die Regierung (oder ein internationales
> Abkommen) festlegt, dass die Grenze hier und da verlaeuft, dann
> verlaeuft sie da, und kein Mapper der Welt kann daran eine (sinnvolle)
> Aenderung vornehmen. Also ist es es unsinnig, fuer sowas eine
> crowdsource-Datenpflege-Engine zu benutzen.


Wenn es die aktuellen Grenzen in definitiver Auflösung überall
verfügbar gäbe stimmte das, davon sind wir aber weit entfernt. In
Deutschland haben wir AFAIK immer noch keine endgültigen Grenzen (die
amtlichen Grenzen sind nicht in der Originalqualität in OSM, und auch
nirgends in einer freien Lizenz (zumindest nicht elektronisch)
verfügbar). In einem großen Projekt wie OSM können wir (=einzelne
Mapper in ihrem Bereich) auf die Behörden zugehen und hoffen, dass sie
uns was "schenken". Nur als große Masse an Leuten können wir das
einigermaßen sinnvoll machen, da steckt ja jede Menge Arbeit dahinter
(wie Du selbst weisst).

Neben einer crowdsource-Datenpflege-Engine ist OSM eben auch ein
crowdgesourceter Datensatz wo Grenzen sehr sinnvoll sind.

Gruß Martin

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


Re: [Talk-de] Relationen "Landmasse"

2011-03-21 Thread Henning Scholland

Am 21.03.2011 19:24, schrieb Frederik Ramm:
"Was ein Mapper nicht sinnvoll bearbeiten kann, gehoert nicht in OSM" 
ist bestimmt kein Spruch, den ich mir ausgedacht habe.
Es ist also in jedem Fall eine Abwaegung. Ganz bestimmt ist es aber 
nicht zulaessig, zu sagen: Wir haben eh schon viel von X, daher kann 
weiteres X ohne Nachzudenken erfasst werden. Im Falle dieser 
unbeobachtbaren, vom Mapper nicht sinnvoll aenderbaren Sachen ist es 
immer eine Einzelfallentscheidung.
Wie du selber festgestellt hast ist das alles eine Grauzone. Die 
Verantwortung, was in OSM eingetragen wird liegt in den Händen des 
einzelnen Mappers. Dann muss man die Entscheidung des Mappers aber auch 
akzeptieren, solange die Daten nicht falsch oder illegal sind. Man kann 
in der Community diskutieren, ob die Art und Weise des Taggings sinnvoll 
ist, oder ob es besser geht und dann ändern.


Eine Anwendung für die Landmasse wäre bspw. die Ermittlung des 
Flächeninhalts der Einheit zu statistischen Zwecken. Oder die Erzeugung 
einer politischen Karte.


Henning


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


Re: [Talk-de] Meeresrelationen

2011-03-21 Thread Christian H. Bruhn
am Sonntag, 20. März 2011 um 22:12 schrieb M∡rtin Koppenhoefer:

> für Dinge wie Kontinente machen wir das aber z.B. nicht (die sind nur
> als Nodes drin).

Da würde ich sagen: NOCH nicht!

> komplizierter, d.h. man muss abwägen. Bei diesen Daten, die
> üblicherweise von einer physischen Karte dargestellt werden, wie
> Bergregionen, Täler, Meere und Meeresteile, Landschaftsräume etc.
> wurde damals in der Diskussion glaube ich auch erwähnt, dass sowas
> (zumindest derzeit) für OSM sehr schlecht geeignet ist und externe
> Daten empfehlenswert sind.

Ja, genau. Extern. Dann machen wir eine Datenbank auf, sammeln dort
alle geografischen Daten. ;-)

Aber wozu sollten dann noch OSM haben, wenn wir alle Daten auslagern?

Wie heißt es doch auf der Wiki-Startseite:
| OpenStreetMap hat das Ziel, freie geographische Daten über Straßen,
| Eisenbahnen, Flüsse, Wälder, Häuser und alles andere, was gemeinhin
| auf Karten zu sehen ist, zu erfassen.

> in OSM. Die Alpen und die Vogesen findest Du nicht, genauso wenig wie
> die Norddeutsche Tiefebene oder den Taunus.

Das Fehlen dieser Dinge ist ist auch ein weiteres Manko von OSM. Auch
diese Daten gehören für mich in OSM. Frederik hatte ja schon mal die
Idee von Fuzzy-Polygonen ins Spiel gebracht; wie ich finde ein guter
Ansatz.

> nur mit OSM-Daten nicht. Ich kann auch die Alpen nicht finden, und
> weiss nicht, wo es im Jahr weniger als 100 mm Niederschlag gibt oder
> wo die monatliche Durchschnittstemperatur 20 Grad übersteigt. Oder wo
> weisse Tiger vorkommen, wo ich mit EUR bezahlen kann oder wo der
> Schengenraum zu Ende ist. Nichtmal, welche Länder Monarchien sind kann
> man herausfinden. Manches davon ist evtl. noch geeignet, in OSM
> aufgenommen zu werden, anderes sicher nicht.

Aber wir reden hier über geografische Basis-Informationen.

>> * Man kann aus der Datenbank keine Informationen zur Größe und Form
>> eines Meeres herausbekommen.

> doch, mit einer externen Quelle (z.B. frei verfügbare Shapefiles) ist
> das problemlos möglich.

Shapefiles, die sich dann wahrscheinlich nicht mit unseren Daten
decken.

> ich finde das Thema auch nicht uninteressant. Problematisch finde ich
> es, wenn wir eine Nullinformation wie "Mittelmeer, 6. Teil", nach
> einem halben Jahr mittlerweile in der 68. Version, mit uns
> rumschleppen müssen, und es nicht so aussieht, als würde daraus noch
> mal was Sinnvolles.

Mensch, löse Dich doch mal vom Term "Teil 6". Die Information steckt
in der Elternrelation, welche übrigens auch schon von mehreren Usern
ergänzt wurde.

Und wenn niemand was ausprobiert oder Vorschläge macht, kommen wir
auch nicht richtig weiter. Das ist OSM. Zumindest hat es schon mal
dazu geführt, daß hier erneut darüber diskutiert wird, wenn auch
leider von zu wenigen Usern.

Christian




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


Re: [Talk-de] Relationen "Landmasse"

2011-03-21 Thread Frederik Ramm

Hallo,

Henning Scholland wrote:
Wie du selber festgestellt hast ist das alles eine Grauzone. Die 
Verantwortung, was in OSM eingetragen wird liegt in den Händen des 
einzelnen Mappers.


Das sage ich auch oft (dass der einzelne von mir aus auch seine 
persoenlichen Daten mappen kann, solang er sich kein Tagging ausdenkt, 
das andere stoert), aber das ist natuerlich immer unter der Annahme, 
dass das im Rahmen bleibt.


Es ist kein Freibrief fuer jemand, jetzt beispielsweise flaechendeckend 
500 GB an historischen Temperaturdaten zu importieren.


Die Freiheit des einzelnen Mappers endet dort, wo sein Vorgehen die 
Freiheit der anderen beschneidet. Es gibt in OSM Relations-Konstrukte, 
die ganz offensichtlich durch ihre Ueberbordende Komplexitaet die 
Freiheit vieler beschraenken.


Dann muss man die Entscheidung des Mappers aber auch 
akzeptieren, solange die Daten nicht falsch oder illegal sind. Man kann 
in der Community diskutieren, ob die Art und Weise des Taggings sinnvoll 
ist, oder ob es besser geht und dann ändern.


Oder ob man es gar nicht will und dann loeschen.

Eine Anwendung für die Landmasse wäre bspw. die Ermittlung des 
Flächeninhalts der Einheit zu statistischen Zwecken. Oder die Erzeugung 
einer politischen Karte.


Ja, allerdings haben wir ja schon festgestellt, dass diese Anwendungen 
durch ein Fehlen der betr. Relationen nicht unmoeglich, sondern nur 
etwas schwieriger wuerden. Insbesondere kann ich mir die Landmasse aller 
Laender der Welt leicht von sowas wie naturalearthdata.com runterladen, 
wenn ich Statistiken oder politische Karten machen will. Das ist also 
eine Disziplin, in der - im Gegensatz zu anderen Disziplinen! - die Welt 
nicht gerade auf OSM gewartet hat.


Bye
Frederik

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

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


Re: [Talk-de] Relationen "Landmasse"

2011-03-21 Thread M∡rtin Koppenhoefer
Am 21. März 2011 19:51 schrieb Henning Scholland :
> Am 21.03.2011 19:24, schrieb Frederik Ramm:
> Eine Anwendung für die Landmasse wäre bspw. die Ermittlung des
> Flächeninhalts der Einheit zu statistischen Zwecken.


und für diesen Spezialfall sollen wir doppelt gemoppelte Daten drin
haben? Diese Landmasse-Relationen sind ja nichtmal dergestalt
redundant, dass man darauf zurückgreifen könnte, wenn die Küstenlinie
kaputt geht: dann sind die nämlich i.d.R. mit kaputt.


> Oder die Erzeugung
> einer politischen Karte.


ich dachte immer, dazu brauchte man Grenzen.


M.E. hat irgendwann jemand mal gelesen, dass die Landmasse bei der
politischen Gliederung eine Rolle spielt (was ja auch stimmt), und
dann den Schluss gezogen, dass man dafür in OSM eine Relation braucht
(das stimmt eben nicht). Daraufhin wurde dieses Vorgehen von anderen
Mappern aufgegriffen und die halbe Welt damit missioniert ("Huch, die
Italiener haben ja noch gar keine Landmasse-Relation, schnell mal eine
erstellen, diese Schlamper tststs").

Wenn wir nun aber feststellen, dass uns diese Relationen praktisch
keine Vorteile bringen, wäre es da nicht am besten, man ergänzte einen
Hinweis im Wiki und löschte diese Relationen wieder, bevor weitere 200
Versionen dazukommen?

Wer vorhat, die Fläche der Landmasse auszurechnen, und in der Lage
ist, seine Datenbank auf eine geeignete Projektion umzustellen, damit
er mit den Werten überhaupt was anfangen kann, der wird auch an der
Subtraktion der Meeresteile nicht scheitern. Ich fände den
Mehraufwand, der einem durch derartige landesweite/weltumspannende
Relationen als Mapper aufgebürdet wird nur dann vertretbar, wenn dem
auch ein Gewinn gegenüberstände.

Gruß Martin

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


Re: [Talk-de] Meeresrelationen

2011-03-21 Thread Frederik Ramm

Hallo,

Christian H. Bruhn wrote:

Shapefiles, die sich dann wahrscheinlich nicht mit unseren Daten
decken.


Das ist ja gerade der Punkt. Wenn es um eine offizielle auf 
Regierungsdaten basierende Information zum Grenzverlauf geht, dann gibt 
es die Frage, ob sich irgendwas deckt oder nicht, nicht. Dann kann ich 
ohne eine Sekunde zu zoegern die externen Daten in meine OSM-Karte 
einzeichnen, und wenn die Grenze dann mitten durch eine Scheune geht, 
dann ist das eben entweder eine falsch eingezeichnete Scheune, oder eine 
multinationale.


Das gleiche gilt fuer sowas wie den "Alpenraum", der hoert ja auch nicht 
praezis an einer Linie auf und kann daher voellig problemlos *ohne* 
Bezug zu OSM-Daten absolut gespeichert werden.


Etwas anderes waere es, wenn es z.B. um einen Datensatz von Fluessen 
ginge; sowas muss man praktisch importieren, weil sonst am Ende die 
Haelfte unserer Bruecken neben statt auf dem Fluss sitzen.


Bye
Frederik

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

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


Re: [Talk-de] Meeresrelationen

2011-03-21 Thread M∡rtin Koppenhoefer
Am 21. März 2011 19:36 schrieb Christian H. Bruhn :
> am Sonntag, 20. März 2011 um 22:12 schrieb M∡rtin Koppenhoefer:


>> komplizierter, d.h. man muss abwägen. Bei diesen Daten, die
>> üblicherweise von einer physischen Karte dargestellt werden, wie
>> Bergregionen, Täler, Meere und Meeresteile, Landschaftsräume etc.
>> wurde damals in der Diskussion glaube ich auch erwähnt, dass sowas
>> (zumindest derzeit) für OSM sehr schlecht geeignet ist und externe
>> Daten empfehlenswert sind.
>
> Ja, genau. Extern. Dann machen wir eine Datenbank auf, sammeln dort
> alle geografischen Daten. ;-)


kommt drauf an, welche Daten. Diese externe Datenbank / Daten gibt es
ja bereits, natural earth ist beispielsweise (AFAIK) PD und bietet
genau sowas. Gerade bei diesen Landschaftsstrichen und Gegenden,
Mittelgebirgen, Gebirgen, Gebirgsteilen, Tälern, etc. etc. ist ja
eines der Probleme, dass es keine genauen Grenzen gibt. Je nach
Maßstab wird man das anders darstellen (und gliedern!), es gibt in der
Realität immer Übergänge. Dafür haben wir in OSM überhaupt kein
Konzept, und auch keine geeignete Editier- oder
Darstellungsmöglichkeit. Und bevor wir nichts von alledem haben,
sollten wir nicht schonmal blind Daten "irgendwie" eintragen.


> Aber wozu sollten dann noch OSM haben, wenn wir alle Daten auslagern?


wir lagern nicht alles aus, sondern das, wofür OSM nie gedacht war und
auch nicht geeignet ist. Verkehrsdaten in realtime z.B., oder
Landstriche und Meeresteile (wobei letztere noch am ehesten geeignet
wären, die haben zumindest mit der Küste eine klare Grenze).

...
>> doch, mit einer externen Quelle (z.B. frei verfügbare Shapefiles) ist
>> das problemlos möglich.
> Shapefiles, die sich dann wahrscheinlich nicht mit unseren Daten
> decken.


Die decken sich mehr als ausreichend. Man kann als Küste ja die von
OSM benutzen. Ich schreibe hier nicht von hypothetischen Dingen, ich
mache das schon, es geht problemlos.



>> ich finde das Thema auch nicht uninteressant. Problematisch finde ich
>> es, wenn wir eine Nullinformation wie "Mittelmeer, 6. Teil", nach
>> einem halben Jahr mittlerweile in der 68. Version, mit uns
>> rumschleppen müssen, und es nicht so aussieht, als würde daraus noch
>> mal was Sinnvolles.
>
> Mensch, löse Dich doch mal vom Term "Teil 6". Die Information steckt
> in der Elternrelation, welche übrigens auch schon von mehreren Usern
> ergänzt wurde.


da steht drin, dass es sich um "das Mittelmeer" handelt. Großartig.
Das wissen ja selbst die Amerikaner ohne Karte ;-)
http://de.wikipedia.org/wiki/Mittelmeer#Gliederung

Wenn der Ersteller sich mit anderen abgesprochen hätte, bevor er
stundenlang eine Relation aus tausenden von Küstenabschnitten
zusammengeclickt hat, dann wäre er vermutlich eher vom Kleinen
ausgegangen. Z.B. Golf von Neapel, hätte diese Schnipsel dann wieder
in Relationen zu Meeren zusammengefasst (z.B. Ionisches Meer,
Tyrrhenisches Meer, Adriatisches Meer, Ägäis), und diese dann wieder
in westliches und östliches Mittelmeer. Ganz zuletzt wäre evtl. noch
ein Mittelmeer aus den beiden letzten entstanden.

Das wäre dann zwar immer noch ein Relationenmonster, aber zumindest
eins, das einen gewissen Sinn macht, und wo ich nicht im Tyrrhenischen
Meer eine Meeresrelation finde, wo die Lagune von Venedig direkt mit
drin ist.

Man hätte an den jeweiligen Küsten noch halbwegs überschaubare und
editierbare Relationen mit wiedererkennbaren Namen, die die
Meeresteile der Umgebung drin haben. Die Zusammenfassung zu größeren
Meeresteilen wäre dann in abstrakteren Relationen, mit denen man sich
eigentlich nicht mehr unbedingt auseinandersetzen muss, solange es im
Kleinen passt.


> Und wenn niemand was ausprobiert oder Vorschläge macht, kommen wir
> auch nicht richtig weiter. Das ist OSM. Zumindest hat es schon mal
> dazu geführt, daß hier erneut darüber diskutiert wird, wenn auch
> leider von zu wenigen Usern.


ja, das stimmt natürlich. Mir tut es auch schon ein bisschen leid,
wenn ich die bisher da geleistete Arbeit so hart kritisiere. Ich würde
unbedingt raten, bevor man das Rad in so einem großen Bereich neu
erfindet, und so viel Arbeit investiert, das vorher mal konkret zu
diskuttieren (ankündigen was man wie vorhat und sich die Kommentare
der Leute ansehen).

Gruß Martin

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


[Talk-de] Probleme mit Nominatim

2011-03-21 Thread Andreas Neumann
Moin,

nachdem ich gesehen hab, dass es hier patente Leute in Fragen Nominatim
gibt, reposte ich mal einen Beitrag aus dem Forum:

Hi,

ich bastle grad an einer website und dachte mir, es sei doch schick, zu
Adressen auch eine kleine Karte anzuzeigen (keine Sorge,
ressourcenschonend). Also schicke ich die Adresse an Nominatim.

Nun bringt mir aber Nominatim, trotz korrekter Daten in OSM (die da
schon seit jahren liegen), die falschen Adressen...

1. beispiel:
bi-Club in Ilmenau. Ist im Haus I, welches die Adressdaten
Max-Planck-Ring 4, 98693 Ilmenau besitzt.
Nun kommt aber das bei der Suche raus:
http://nominatim.openstreetmap.org/search?q=bi+club+ilmenau&format=xml&addressdetails=1&zoom=18
Die Albert-Einstein ist tatsächlich die nächstliegende, jedoch hat er
sich früher an die Adressdaten gehalten :-(

2. Beispiel:
(Anmerkung, ich nehme immer nur den ersten Treffer)
Manggasse 8 in Ilmenau. Das Haus gibts nur einmal!
Bei den Treffern kommt nun:
http://nominatim.openstreetmap.org/search?q=manggasse+8+ilmenau&format=xml&addressdetails=1&zoom=18
Der erste Treffer ist die Lindenstraße 8 (auch komplett getagt), welche
aber an der Einmündung Manggasse->Lindenstraße steht. erst der zweite
Treffer ist die richtige Manggasse 8 (auch hier sind alle addr:*-tags drin).

3. Beispiel:
Der Audimax ist im Humboldtbau, welcher alle addr:*-Tags besitzt. Also
müsste er die korrekte PLZ 98693 bekommen, aber:
http://nominatim.openstreetmap.org/search?q=manggasse+8+ilmenau&format=xml&addressdetails=1&zoom=18
98704 ist der Nachbarort. Auch die PLZ-Multipolygone liegen korrekt...

4. Überall in Ilmenau und Umgebung gilt als Ortsteil "Oehrenstock". Dies
ist ein Ortsteil von Langewiesen.
http://nominatim.openstreetmap.org/search?q=ehrenbergstraße+ilmenau&format=xml&addressdetails=1&zoom=18
Den nähesten Ortsteil anzugeben ist ja schön und gut, jedoch gibt es
viele Ortsteile, die keinen Namen haben! Ich weiß, das ist sehr schwer
zu berechnen, aber evtl. finden ja die Theoretiker hier im Raum einen Weg...

Ist das nur ein Temporäres Problem? Machen wir was beim Tagging falsch?
Hab ich falsche Ansprüche an Nominatim?

Hoffe irgendwer kann mir helfen :-D

MfG Andreas

-- 
Diese Nachricht wurde maschinell erstellt und ist daher ohne
Unterschrift gültig.



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


[Talk-de] lnm: Japan: Freie Geodaten im Katastropheneinsatz

2011-03-21 Thread Benjamin Hagemann
Moin :)

fyi

lnm: Japan: Freie Geodaten im Katastropheneinsatz
http://www.linux-magazin.de/NEWS/Japan-Freie-Geodaten-im-Katastropheneinsatz

-- 
Grüße, Benny

gpg 0xFC505AB0
jabber  be...@benny.de
sip be...@benny.de


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