Hallo Stefan, alle, (hat jemand einen Fachbegriff fuer "Detailtiefe", bitte?)
[email protected] (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) _______________________________________________ Talk-at mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-at
