[Talk-at] Detailtiefe [War: Re: Wann ist zuviel zuviel]

MERIGHI Marcus mcmer-openstreetmap at tor.at
Wed Dec 7 18:34:26 UTC 2011


Hallo Stefan, alle, 

(hat jemand einen Fachbegriff fuer "Detailtiefe", bitte?)

stefan at kopetzky.net (Stefan Kopetzky), 2011.12.02 (Fri) 15:19 (CET):
> On 02.12.2011 14:21, MERIGHI Marcus wrote:
> > warum sind dann meine verd...... Hoehenlinien (NASA SRTM) nicht in der
> > DB?! (scherzhaft mit wahrem Kern)
> Ich vermute mal vorrangig aus Lizenzgründen...
> Zudem gibts wenig (ich kenn keine auf der Ebene, auf der wir uns hier
> bewegen) Möglichkeiten bessere Höhenlinien zu erzeugen. Also ist es auch
> eher nicht sinnvoll Höhenlinien editieren zu können.  Wäre das anders
> würde auch wenig dagegen sprechen sie aufzunehmen.
> >> Es besteht die Möglichkeit die Daten, die man Rendern möchte davor
> >> genauer auszuwählen bzw. einzuschränken. 
> > Es waer' in gegenstaendlichen Fall aber schwierig; ich kann natuerlich
> > sagen: gib' mir nix, was natural=wood (oder eigentlich natural=scrub)
> > ist, aber das ist ja nicht wirklich das, was ich will; ich moechte
> > eigentlich:
> > gib' mir natural=scrub, aber simplified.
> > Oder vielleicht mit layers? Ein grosses Latschenfeld auf einer
> > allgemeineren Ebene, volle Details auf einer anderen?
> Geometrie und Graphentheorie liefern da alle (aus meinem Blickwinkel -
> bin, nur leidlich mathematisch begabter, Informatiker und kein
> Kartograph) nötigen Grundlagen.
> Grundsätzlich liegt mMn das Abstrahieren und die Konfiguration desselben
> beim Renderer. Dass das kein aktueller kann, ist bedauerlich, sollte
> sich aber nicht auf die Erfassung der Daten durchschlagen.

OK, spielen wir es durch. Wir nehmen keine Ruecksicht auf die
Datenmenge. Alles sei moeglich. Es bleibt dennoch die Frage der Grenze.
Wo hoerst Du dann auf zu mappen? Was ist mappen und was ist malen? Soll
ich - theoretisch - die einzelnen (Stolper-) Steine am Wanderweg
einzeichnen?

Ich waer' echt voll froh ueber eine Klaerung...

> >> Douglas-Peucker (imho der beim
> > http://wiki.osm.org/Douglas-Peucker ist nicht gerade aufbauend.
> >> > JOSM - "Shift-Y" - verwendete) u.ä Algorithmen kann man auch vorm
> >> > Renderen einsetzen, 
> > Das ist aber jetzt eher theoretisch, oder? Wenn nicht, dann bitte her
> > mit dem know-how!
> 
> Je nachdem was du unter "theoretisch" verstehst. Ich glaub nicht, dass
> es dzt. in einem fertigen Renderer eingebaut ist, aber es wäre mMn
> technisch kein Problem das zu tun. Friedrich hat ja heute schon
> angesprochen, dass die Software da der Zeit hinterherhinkt. Diese
> Einschätzung teile ich.
 
Die einzige amtliche (im Sinne von keine Software XYZ die nur mit ABC
auf DEF laeuft wenn der Benutzername der gleiche ist wie jener des
Programmierers :-) Loesung, die ich fand, ist osmosis. Plugins
simpflifyway und tagtransform gemeinsam schaffen's dann. Auch noch einen
osmosis bug (tee vs. merge) gestreift, sche woas. 

Hilft mir wenigstens mit gpsmid.

Pfirteich, Marcus

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Wegvereinfachung Testergebnisse (simplifyways epsilonMeters=10):

contours (.0 = _vor_ bearbeitung) (srtm -> shape -> osm, 20m steps):
8.6M    hoellen.osm
14.8M   hoellen.osm.0
12.6M   muehlv.osm
19.3M   muehlv.osm.0
36.0M   sengseng.osm
61.3M   sengseng.osm.0
53.1M   totes.osm
92.2M   totes.osm.0

osm daten (hoellengebirge)
17.6M   test.osm
26.3M   test.osm.downloaded
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#!/bin/sh -e
if [[ $# -lt 2 ]]; then
	print -u2 "usage: osm-norm.sh source target maxerr"
	exit
fi
#
local _src="${1}"
local _tgt="${2}"
local _err="${3:-10}"
#
# temp location needs to provide some space!
_td=$(mktemp -t -d osmnorm-XXXXXX)
_fnnorm="${_td}/norm.osm"
_fnused="${_td}/used.osm"
_fnpois="${_td}/pois.osm"
_fndiff="${_td}/diff.osm"

print simplify-ways
osmosis \
  -quiet 0 \
  --read-xml file="${_src}" outPipe.0=source \
  --sort inPipe.0=source outPipe.0=sourcesort \
  --simplify-ways epsilonMeters="${_err}" inPipe.0=sourcesort outPipe.0=norm \
  --sort inPipe.0=norm outPipe.0=normsort \
  --write-pbf inPipe.0=normsort file="${_fnnorm}" 

print used-node
osmosis \
  -quiet 0 \
  --read-pbf file="${_fnnorm}" outPipe.0=norm \
  --used-node inPipe.0=norm outPipe.0=usedonly \
  --sort inPipe.0=usedonly outPipe.0=usedonlysort \
  --write-pbf inPipe.0=usedonlysort file="${_fnused}" 

print derive-change
osmosis \
  -quiet 0 \
  --read-pbf file="${_fnnorm}" outPipe.0=norm \
  --read-pbf file="${_fnused}" outPipe.0=used \
  --derive-change inPipe.0=used inPipe.1=norm outPipe.0=diff \
  --sort-change inPipe.0=diff outPipe.0=diffsort \
  --read-empty outPipe.0=empty \
  --apply-change inPipe.0=empty inPipe.1=diffsort outPipe.0=diffosm \
  --write-pbf inPipe.0=diffosm file="${_fndiff}" 
 
print tag-transform, node-key
osmosis \
  -quiet 0 \
  --read-pbf file="${_fndiff}" outPipe.0=diffosm \
  --tag-transform file="${HOME}/.nonemptynodes.xml" inPipe.0=diffosm outPipe.0=tt \
  --node-key keyList="is_poi" inPipe.0=tt outPipe.0=pois \
  --write-pbf inPipe.0=pois file="${_fnpois}" 

print merge
osmosis \
  -quiet 0 \
  --read-pbf file="${_fnused}" outPipe.0=used \
  --read-pbf file="${_fnpois}" outPipe.0=pois \
  --merge inPipe.0=used inPipe.1=pois outPipe.0=merged \
  --write-xml inPipe.0=merged file="${_tgt}" 

rm -rf "${_td}"
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
theoretisch sollte auch das gehen, aber: tee vs. merge, siehe
http://wiki.openstreetmap.org/wiki/Osmosis/Detailed_Usage#--tag-filter_.28--tf.29
(bei den Beispielen)

osmosis \
  -quiet 0 \
  --read-xml file="${_src}" outPipe.0=source \
  --sort inPipe.0=source outPipe.0=sourcesort \
  --simplify-ways epsilonMeters="${_err}" inPipe.0=sourcesort outPipe.0=norm \
  --sort inPipe.0=norm outPipe.0=normsort \
  --tee inPipe.0=normsort outPipe.0=fullnorm outPipe.1=to_usedonly \
  --used-node inPipe.0=to_usedonly outPipe.0=usedonly \
  --sort inPipe.0=usedonly outPipe.0=usedonlysort \
  --tee inPipe.0=usedonlysort outPipe.0=usedonlymerge outPipe.1=usedonlydiff \
  --derive-change inPipe.0=usedonlydiff inPipe.1=fullnorm outPipe.0=diff \
  --sort-change inPipe.0=diff outPipe.0=diffsort \
  --read-empty outPipe.0=empty \
  --apply-change inPipe.0=empty inPipe.1=diffsort outPipe.0=diffosm \
  --tag-transform file="${HOME}/.nonemptynodes.xml" inPipe.0=diffosm outPipe.0=tt \
  --node-key keyList="is_poi" inPipe.0=tt outPipe.0=pois \
  --merge inPipe.0=usedonlymerge inPipe.1=pois outPipe.0=merged \
  --write-xml inPipe.0=merged file="${_tgt}" 

> >> > Datenbasis != Karte != Realität
> > Good catch! (Musst Du alles noch komplizierter machen? :-)
> > 
> > Realitaet:  Alles.
> > Datenbasis: alles, was technisch und inhaltlich Sinn macht (die
> >             Sinnfrage bleibt weiter ungeklaert)
> >             [Eine umfassende aber unbrauchbare Datenbank bringt auch
> >             nix, oder?]
> > Karte:      alles, was notwendig ist fuer einen bestimmten Zweck,
> >             Zielgruppe, ...
> > 
> > So ungefaehr?
> Jup!
> Wobei ich ganz froh bin, dass die Sinnfrage ungeklärt ist (siehe
> de.wikipedia & Relevanz)




More information about the Talk-at mailing list