Re: [Talk-de] Gebäude-Mapping

2010-11-08 Diskussionsfäden Peter Wendorff

Am 08.11.2010 12:30, schrieb M∡rtin Koppenhoefer:

Am 8. November 2010 11:25 schrieb Peter Wendorff:

Abgesehen davon überlege ich noch, wie ein Rendering am besten umgesetzt
würde - speziell in dem Fall, wenn nicht für alle Gebäudeteile absolute
height/min_height-Werte vorhanden sind.
Ein Stockwerk ist ja nicht bei jedem Gebäude gleich hoch, und
insbesondere auch nicht auf derselben absoluten Höhe. Also müsste ein
Renderer wohl so vorgehen:
* in einem ersten Schritt Gruppen von sich (ggf. transitiv)
überlappenden Gebäudeteilen bestimmen
* innerhalb jeder Gruppe absolute Höhen der Stockwerksgrenzen festlegen
* mit dieser Information dann die Grundflächen der Gebäudeteile zwischen
den jeweiligen Stockwerksgrenzen extrudieren
Wäre eine solche Auswertung das, was du dir vorgestellt hast, oder
hättest du eine andere - ggf. sogar einfachere - Idee?

Jein.
Ich würde einen einfacheren Ansatz vorziehen, der meist zu einem Ergebnis
führen dürfte und zusätzlich unnötige Fehler behebt:
Dabei fällt dein erster Schritt weg:
* Stockwerkhöhe wird, wenn nicht anders angegeben, konstant angenommen. Es
lässt sich also aus den Stockwerkangaben eine meter-Angabe berechnen, die
für nicht gesetzte Meterangaben herangezogen wird.

in der Architektur nimmt man i.d.R. für vereinfachende
Städtebaumodelle meist 2 Höhen an, grob vereinfacht für "Neubauten"
(ca. ab 50er Jahre) 3 m und für Altbauten (davor) ca. 4 m. Das reicht
für grobe Modelle schon aus. Wenn man die Gebäudetypen hat kann man
noch weitergehende Annahmen treffen. Das Erdgeschoss ist oft etwas
höher (generalisiert ca. 5m), insb. wenn es eine vom Rest abweichende
Nutzung hat. Dazu kommt je nach Dach ggf. nochmal eine Attika oder ein
sonstiger oberer Abschluss (Dachbühne, etc.), je nach Typ und
Dachneigung 1m bis 5-8 m.

Diese Höhen sind Geschosshöhen, also Deckenkonstruktion + Raumhöhe.

Für Architektur nicht schlecht und sicher auch hier machbar.
Dachkonstruktionen hab ich allerdings bewusst hier nicht beachtet, da 
mein Ziel ein anderes ist.


Mir geht es nicht in erster Linie um eine korrekte 3D-Darstellung des 
Gebäudes - die gehört tatsächlich in externe Modelle und hat in OSM 
direkt nichts zu suchen: spätestens bei bestimmten Details sind die 
Daten sonst nicht mehr handhabbar.
Mir ging und geht es eher darum, auch 3dimensional gültige 
Navigationsgraphen erzeugen zu können und Geschäfte etc. auch innerhalb 
eines Gebäudes korrekt zuordnen zu können.

Dabei entstehende Fehler lassen sich jeweils durch die Angabe der einzelnen
Höhen beheben.

genau, ist aber schon aufwendiger: man braucht bei simplen geneigten
Dächern (Satteldach, Pultdach, etc.) eigentlich vereinfacht nur 3
Höhen: Erdboden, Firsthöhe und Traufhöhe. Dazuhin sollte man wissen,
wie die Ausrichtung des Daches ist. Bei assymetrischen Dächern ist
auch die Neigung (oder die Lage des Firstes) erforderlich (ergibt sich
sonst automatisch). Komplexere Dächer sind nochmal ein Thema für sich.
Für die einfachen Fälle (aber über Flachdach hinaus) gibt es auch hier 
bereits proposals [1].

Die o.g. Vorgehensweise geht für viele Gebäude ganz gut, aber nur für
die "langweiligen", sobald Du Splitlevel oder gar geneigte
Bodenflächen (Rampen etc.) hast, wird es komplexer.

Das ist richtig.
Für eine genaue Beschreibung geht IMHO nichts an externen 3D-Modellen 
vorbei.

Ein größeres Problem, zu dem mir tatsächlich noch keine Lösung einfällt,
besteht bei Gebäuden am Hang, bei denen das "Erdgeschoss" je nach Seite
unterschiedlich ist. Hier sehe ich aber auch keine Lösung, ohne Höhendaten
der Umgebung hinzuzufügen, die uns bisher vollständig fehlen.

Das wäre auch nochmal ein Spezialfall, ja, aber sobald Du 2
Erdgeschosshöhen zuordnest wäre dieser Fall geklärt.
Dafür müssten aber leider Attribute an TEILE von Polygonen gepappt 
werden, denn ein Attribut am Polygon kann nur sagen Erdgeschoss oder 
nicht-erdgeschoss. Zu beschreiben "Erdgeschoss auf den südlichen zwei 
Dritteln der Ostseite und dem östlichen viertel der Südseite" ist glaub 
ich nicht so ohne weiteres verwendbar möglich.

  Denkbar sind ja
auch Gebäude mit Tiefhof, G. in einer "künstlichen" Landschaft
(Treppen, Podeste, Plattformen, Plätze, etc., alles Teil des Gebäudes
bzw. drum rum, z.B. sowas hier:
http://mw2.google.com/mw-panoramio/photos/medium/4731995.jpg
http://www.roppongihills.com/common/img/en/ph_sr_index_vi_01.jpg

Klar.
Aber hier bewegen wir uns auf die Notwendigkeit eines Höhenmodells zu; 
ein Thema, das bisher ausschließlich umgangen worden ist, soweit ich 
weiß: Höhenlinien werden für einige Karten importiert, aber immer aus 
externen Quellen und ohne Auswirkungen auf das restliche Rendering.


Ich hielte es auch für keine gute Idee, Höhenlinien vermischt mit den 
restlichen Daten zu taggen;
hier könnte man aber hervorragend einen tatsächlich dedizierten 
zusätzlichen Layer in der API einführen, der von Editoren etc. auch 
ausgewertet werden könnte. (das ist aber ein großes Fass, das ich 
persönlich gar nicht austrinken möchte - selbst wenn ich

Re: [Talk-de] Gebäude-Mapping

2010-11-08 Diskussionsfäden M∡rtin Koppenhoefer
Am 8. November 2010 11:25 schrieb Peter Wendorff :

>> Abgesehen davon überlege ich noch, wie ein Rendering am besten umgesetzt
>> würde - speziell in dem Fall, wenn nicht für alle Gebäudeteile absolute
>> height/min_height-Werte vorhanden sind.
>> Ein Stockwerk ist ja nicht bei jedem Gebäude gleich hoch, und
>> insbesondere auch nicht auf derselben absoluten Höhe. Also müsste ein
>> Renderer wohl so vorgehen:
>> * in einem ersten Schritt Gruppen von sich (ggf. transitiv)
>> überlappenden Gebäudeteilen bestimmen
>> * innerhalb jeder Gruppe absolute Höhen der Stockwerksgrenzen festlegen
>> * mit dieser Information dann die Grundflächen der Gebäudeteile zwischen
>> den jeweiligen Stockwerksgrenzen extrudieren
>> Wäre eine solche Auswertung das, was du dir vorgestellt hast, oder
>> hättest du eine andere - ggf. sogar einfachere - Idee?
>
> Jein.
> Ich würde einen einfacheren Ansatz vorziehen, der meist zu einem Ergebnis
> führen dürfte und zusätzlich unnötige Fehler behebt:
> Dabei fällt dein erster Schritt weg:
> * Stockwerkhöhe wird, wenn nicht anders angegeben, konstant angenommen. Es
> lässt sich also aus den Stockwerkangaben eine meter-Angabe berechnen, die
> für nicht gesetzte Meterangaben herangezogen wird.


in der Architektur nimmt man i.d.R. für vereinfachende
Städtebaumodelle meist 2 Höhen an, grob vereinfacht für "Neubauten"
(ca. ab 50er Jahre) 3 m und für Altbauten (davor) ca. 4 m. Das reicht
für grobe Modelle schon aus. Wenn man die Gebäudetypen hat kann man
noch weitergehende Annahmen treffen. Das Erdgeschoss ist oft etwas
höher (generalisiert ca. 5m), insb. wenn es eine vom Rest abweichende
Nutzung hat. Dazu kommt je nach Dach ggf. nochmal eine Attika oder ein
sonstiger oberer Abschluss (Dachbühne, etc.), je nach Typ und
Dachneigung 1m bis 5-8 m.

Diese Höhen sind Geschosshöhen, also Deckenkonstruktion + Raumhöhe.



> Dabei entstehende Fehler lassen sich jeweils durch die Angabe der einzelnen
> Höhen beheben.


genau, ist aber schon aufwendiger: man braucht bei simplen geneigten
Dächern (Satteldach, Pultdach, etc.) eigentlich vereinfacht nur 3
Höhen: Erdboden, Firsthöhe und Traufhöhe. Dazuhin sollte man wissen,
wie die Ausrichtung des Daches ist. Bei assymetrischen Dächern ist
auch die Neigung (oder die Lage des Firstes) erforderlich (ergibt sich
sonst automatisch). Komplexere Dächer sind nochmal ein Thema für sich.

Die o.g. Vorgehensweise geht für viele Gebäude ganz gut, aber nur für
die "langweiligen", sobald Du Splitlevel oder gar geneigte
Bodenflächen (Rampen etc.) hast, wird es komplexer.


> Ein größeres Problem, zu dem mir tatsächlich noch keine Lösung einfällt,
> besteht bei Gebäuden am Hang, bei denen das "Erdgeschoss" je nach Seite
> unterschiedlich ist. Hier sehe ich aber auch keine Lösung, ohne Höhendaten
> der Umgebung hinzuzufügen, die uns bisher vollständig fehlen.


Das wäre auch nochmal ein Spezialfall, ja, aber sobald Du 2
Erdgeschosshöhen zuordnest wäre dieser Fall geklärt. Denkbar sind ja
auch Gebäude mit Tiefhof, G. in einer "künstlichen" Landschaft
(Treppen, Podeste, Plattformen, Plätze, etc., alles Teil des Gebäudes
bzw. drum rum, z.B. sowas hier:
http://mw2.google.com/mw-panoramio/photos/medium/4731995.jpg
http://www.roppongihills.com/common/img/en/ph_sr_index_vi_01.jpg

Gruß Martin

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


Re: [Talk-de] Gebäude-Mapping

2010-11-08 Diskussionsfäden Peter Wendorff

Hallo Tobias.
Am 08.11.2010 11:02, schrieb Tobias Knerr:

Am 05.11.2010 23:14, schrieb Peter Wendorff:

Ich plane aber, in den nächsten Wochen/Monaten daran weiterzubasteln und
es auch in einen normalen Proposal-Prozess einzubringen.
Auch in der Hinsicht sind mir Kommentare und Verweise zu anderen
Schemata natürlich willkommen.

Ich hoffe, du findest die Zeit, ein Proposal zu dem Thema zu entwickeln.

Noch einmal eine konkrete Frage zu deinem Vorschlag: Werden die Tags
"building:levels=*" allein verwendet oder jeweils gemeinsam mit
building=yes? Gibt es also genau ein Objekt mit building=yes für das
gesamte Gebäude, an den dann Namen, Relationsmitgliedschaften etc.
angebracht werden können, oder "zerfällt" das Gebäude?
Momentan bekommt jedes Polygon ein building=yes, und zwar aus rein 
praktischen Gründen: Auf diese Weise werden aktuelle Renderer, die das 
nicht unterstützen, das Gebäude insgesamt weitgehend korrekt rendern, 
nämlich die insgesamt abgedeckte Fläche - unter Umständen mit 
zusätzlichen Konturlinien.
Das ist semantisch nicht ganz korrekt, das ist mir klar; aber eben aus 
Kompatibilitätsgründen IMHO die beste Lösung, ohne Gebäude für renderer 
"kaputtzumachen".

Abgesehen davon überlege ich noch, wie ein Rendering am besten umgesetzt
würde - speziell in dem Fall, wenn nicht für alle Gebäudeteile absolute
height/min_height-Werte vorhanden sind.
Ein Stockwerk ist ja nicht bei jedem Gebäude gleich hoch, und
insbesondere auch nicht auf derselben absoluten Höhe. Also müsste ein
Renderer wohl so vorgehen:
* in einem ersten Schritt Gruppen von sich (ggf. transitiv)
überlappenden Gebäudeteilen bestimmen
* innerhalb jeder Gruppe absolute Höhen der Stockwerksgrenzen festlegen
* mit dieser Information dann die Grundflächen der Gebäudeteile zwischen
den jeweiligen Stockwerksgrenzen extrudieren
Wäre eine solche Auswertung das, was du dir vorgestellt hast, oder
hättest du eine andere - ggf. sogar einfachere - Idee?

Jein.
Ich würde einen einfacheren Ansatz vorziehen, der meist zu einem 
Ergebnis führen dürfte und zusätzlich unnötige Fehler behebt:

Dabei fällt dein erster Schritt weg:
* Stockwerkhöhe wird, wenn nicht anders angegeben, konstant angenommen. 
Es lässt sich also aus den Stockwerkangaben eine meter-Angabe berechnen, 
die für nicht gesetzte Meterangaben herangezogen wird.

* Die einzelnen Polygone werden entsprechend extrudiert.

Warum reicht das aus bzw. was hat das zur Folge?

Angenommen, die untere "Schicht" (Stockwerk 1) hat keine explizit 
angegebene Höhe, die darüberliegende Schicht (Stockwerk 2) aber schon.
Dann lässt sich dieser Fehler alleine aus den Daten heraus beheben (wenn 
auch das rein algorithmische Beheben aufwändig sein dürfte).


Deshalb nehme ich bei oben beschriebenem Algorithmus in Kauf, dass in 
diesen Fällen Lücken oder Überlappungen sichtbar werden: Die Fehler 
sollen bitte behoben werden - und nichts spricht dagegen.


Solange also keine unterschiedlichen Stockwerkhöhen aus dem Gebäudetypen 
oder so abgeleitet werden sollen, reicht dieses Verfahren aus. Bei 
Kirchen etc. wird es natürlich trotzdem zu Problemen führen - aber 
sobald Stockwerke in einem Gebäudekomplex nicht mehr gleich hoch sind 
(gerade bei Kirchen oft der Fall), hilft dein Verfahren da auch nicht 
weiter.


Dabei entstehende Fehler lassen sich jeweils durch die Angabe der 
einzelnen Höhen beheben.


Ein größeres Problem, zu dem mir tatsächlich noch keine Lösung einfällt, 
besteht bei Gebäuden am Hang, bei denen das "Erdgeschoss" je nach Seite 
unterschiedlich ist. Hier sehe ich aber auch keine Lösung, ohne 
Höhendaten der Umgebung hinzuzufügen, die uns bisher vollständig fehlen.


Gruß
Peter

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


Re: [Talk-de] Gebäude-Mapping

2010-11-08 Diskussionsfäden Tobias Knerr
Am 05.11.2010 23:14, schrieb Peter Wendorff:
> Ich plane aber, in den nächsten Wochen/Monaten daran weiterzubasteln und
> es auch in einen normalen Proposal-Prozess einzubringen.
> Auch in der Hinsicht sind mir Kommentare und Verweise zu anderen
> Schemata natürlich willkommen.

Ich hoffe, du findest die Zeit, ein Proposal zu dem Thema zu entwickeln.

Noch einmal eine konkrete Frage zu deinem Vorschlag: Werden die Tags
"building:levels=*" allein verwendet oder jeweils gemeinsam mit
building=yes? Gibt es also genau ein Objekt mit building=yes für das
gesamte Gebäude, an den dann Namen, Relationsmitgliedschaften etc.
angebracht werden können, oder "zerfällt" das Gebäude?

Abgesehen davon überlege ich noch, wie ein Rendering am besten umgesetzt
würde - speziell in dem Fall, wenn nicht für alle Gebäudeteile absolute
height/min_height-Werte vorhanden sind.
Ein Stockwerk ist ja nicht bei jedem Gebäude gleich hoch, und
insbesondere auch nicht auf derselben absoluten Höhe. Also müsste ein
Renderer wohl so vorgehen:
* in einem ersten Schritt Gruppen von sich (ggf. transitiv)
überlappenden Gebäudeteilen bestimmen
* innerhalb jeder Gruppe absolute Höhen der Stockwerksgrenzen festlegen
* mit dieser Information dann die Grundflächen der Gebäudeteile zwischen
den jeweiligen Stockwerksgrenzen extrudieren

Wäre eine solche Auswertung das, was du dir vorgestellt hast, oder
hättest du eine andere - ggf. sogar einfachere - Idee?

Tobias Knerr

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


Re: [Talk-de] Gebäude-Mapping

2010-11-06 Diskussionsfäden M∡rtin Koppenhoefer
Am 5. November 2010 18:36 schrieb Peter Wendorff :

> und auch wenn das noch auf meiner User-Seite liegt: Kommentare sind herzlich
> willkommen.


Wer rendert denn Aufrisse aus OSM-Daten? Die Renderbeispiele sind IMHO
sinnlos, ich würde Grundrisse vorschlagen. Mit derzeitigen Editoren
ist sowas sehr schwer einzutragen. Ein Workflow wäre z.B. doppelte
Wege zu zeichnen (wg. des Snappings) und diese dann mit unglue zu
entkoppeln. Vertikale Verbindungen wirst Du nicht zeichnen wollen?

M.E. kommt man damit auch an die Auflösungsgrenzen des derzeitigen
Modells. Ich bin nach wie vor für externe Modelle, die verlinkt
werden. Für den Weg unter dem Gebäude kann man in OSM covered
verwenden. Durch die Linearität unserer Wege-Daten sind allerdings
Fußgängerflächen grundsätzlich schlecht repräsentierbar.

Gruß Martin

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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden Peter Wendorff

Am 05.11.2010 22:29, schrieb Johannes Huesing:

Martin Simon  [Fri, Nov 05, 2010 at 09:57:52PM CET]:

Ich fürchte ich habe den Thread damit ein wenig gekapert; bei meiner
Antwort ging es gar nicht so sehr um die Fragestellung mit den Seilen
des Funkmastes, sondern um dieses allgemeine Konzept für "gestückelte"
Gebäude, das ich mal in den Raum stellen wollte.

Keine Ursache, der Titel des Threads erfasst Deine Ausführungen genauso,
aber alle, die mit uns auf Kaperfahrt gehn, müssen Männer mit Bärten sein.

(ok) Anforderung erfüllt.


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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden Peter Wendorff

Am 05.11.2010 23:01, schrieb Martin Simon:

Am 5. November 2010 18:36 schrieb Peter Wendorff:

Am Unicampus Paderborn habe ich dazu ein Schema [1] verwendet und auch mit
Komzpa (Entwickler von Kothic) abgestimmt.

Bin bisher nicht dazu gekommen, das komplett fertigzumachen und in 'nen
Proposal-Prozess einzubringen, aber hier passt das vielleicht rein,
und auch wenn das noch auf meiner User-Seite liegt: Kommentare sind herzlich
willkommen.

Hallo Peter!

Das Schema war mir noch gar nicht über den Weg gelaufen. Vielleicht
kann man die Vorteile aus allen Ansätzen kombinieren. :-)
Dass Dir das noch nicht über den Weg gelaufen ist, hab ich mir gedacht; 
bisher hab ich es auch noch praktisch nicht beworben, und (außer in 
meiner Bachelorarbeit als Randnotiz) nirgendwo verlinkt.
Im Grunde genommen ist das im momentanen Zustand ein Abfallprodukt von 
"wie mappe ich" ;)
Ich plane aber, in den nächsten Wochen/Monaten daran weiterzubasteln und 
es auch in einen normalen Proposal-Prozess einzubringen.
Auch in der Hinsicht sind mir Kommentare und Verweise zu anderen 
Schemata natürlich willkommen.

Du schneidest dabei deine Gebäude horizontal, ich hatte eher eine
vertikale Unterteilung im Sinn (bei deinem Beispiel(von links nach
rechts): A: [7 Stockwerke], B: [5 Stockwerke, beginnend mit dem 3.],
A: [7 Stockwerke]).
Damit könnte man alles in einem Abwasch erledigen und sowohl solche
Durchlässe als auch unterschiedliche Dachhöhen darstellen. Hat das
horizontale schneiden einen Vorteil dem gegenüber, den ich übersehe?
Bei den Universitätsgebäuden in Paderborn hat das horizontale Schneiden 
vor allem praktisch einen Vorteil; die Alternative hab ich gar nicht als 
solche gesehen gehabt zu dem Zeitpunkt.


Hab jetzt ernsthaft etwas über die Frage nachdenken müssen ;)

Ich denke aber, es gibt einen Vorteil:
Schneidet man vertikal in einzelne "Säulen", geht der Zusammenhang der 
Etage verloren.
Beim horizontalen Schneiden beschreibt ein Polygon immer noch die 
Außenwand dieses Stockwerks, was insbesondere zusätzlich das mapping von 
Innenwänden später erlauben würde.
Betrachtet man ein Gebäude, das z.B. eine Brücke bildet, dann ist die 
senkrechte Wand mittendrin eben nur da, wo auf einer Seite davon nichts 
mehr ist - das beschreibt mein Ansatz.


Gruß
Peter

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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden Martin Simon
Am 5. November 2010 18:36 schrieb Peter Wendorff :
> Am Unicampus Paderborn habe ich dazu ein Schema [1] verwendet und auch mit
> Komzpa (Entwickler von Kothic) abgestimmt.
>
> Bin bisher nicht dazu gekommen, das komplett fertigzumachen und in 'nen
> Proposal-Prozess einzubringen, aber hier passt das vielleicht rein,
> und auch wenn das noch auf meiner User-Seite liegt: Kommentare sind herzlich
> willkommen.

Hallo Peter!

Das Schema war mir noch gar nicht über den Weg gelaufen. Vielleicht
kann man die Vorteile aus allen Ansätzen kombinieren. :-)

Du schneidest dabei deine Gebäude horizontal, ich hatte eher eine
vertikale Unterteilung im Sinn (bei deinem Beispiel(von links nach
rechts): A: [7 Stockwerke], B: [5 Stockwerke, beginnend mit dem 3.],
A: [7 Stockwerke]).
Damit könnte man alles in einem Abwasch erledigen und sowohl solche
Durchlässe als auch unterschiedliche Dachhöhen darstellen. Hat das
horizontale schneiden einen Vorteil dem gegenüber, den ich übersehe?

Gruß,

Martin

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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden Martin Simon
Am 5. November 2010 22:29 schrieb Johannes Huesing :

> Keine Ursache, der Titel des Threads erfasst Deine Ausführungen genauso,
> aber alle, die mit uns auf Kaperfahrt gehn, müssen Männer mit Bärten sein.

[x] check! ;-)

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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden Johannes Huesing
Martin Simon  [Fri, Nov 05, 2010 at 09:57:52PM CET]:
> Ich fürchte ich habe den Thread damit ein wenig gekapert; bei meiner
> Antwort ging es gar nicht so sehr um die Fragestellung mit den Seilen
> des Funkmastes, sondern um dieses allgemeine Konzept für "gestückelte"
> Gebäude, das ich mal in den Raum stellen wollte.

Keine Ursache, der Titel des Threads erfasst Deine Ausführungen genauso,
aber alle, die mit uns auf Kaperfahrt gehn, müssen Männer mit Bärten sein.

-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden Martin Simon
Hallo Johannes, Hallo Martin,

Ich fürchte ich habe den Thread damit ein wenig gekapert; bei meiner
Antwort ging es gar nicht so sehr um die Fragestellung mit den Seilen
des Funkmastes, sondern um dieses allgemeine Konzept für "gestückelte"
Gebäude, das ich mal in den Raum stellen wollte.

(wie wär's mit man_made=cable, cable=suspension als Mitglied in einer
Building-Relation zusammen mit dem Mast und den Widerlagern?)


Am 5. November 2010 13:22 schrieb M∡rtin Koppenhoefer :
>> Hm, wenn du Martin in dieser Frage beipflichtest, heißt die Lösung für
>> deine Seile wohl building=yes. :-p
>
>
> building=rope wäre das analog. Im Bsp. Sony Center war das mit
> building=roof getaggt, nicht yes. Dieser Unterschied ist m.E. nicht
> unbedeutend.

OK, habe ich unterschlagen. ;-)
Ja, nicht unbedeutend, nur tritt es leider damit immer noch als
"eigenständiges" Gebäude auf.

> ja, volle Zustimmung. Das bräuchten wir eigentlich. Sobald wir ins
> 2,5D gehen wollen (mit Höhen) kann es gar nicht ausbleiben, einen
> Umriss für jeden unterschiedlich hohen bzw. mit eigenem Dach
> ausgestatteten Baukörper zu haben. Man könnte den Kirchturm vom Schiff
> trennen, etc.

Ja, schön illustriert werden diese Möglichkeiten ja bereits z.B. bei
www.osm-3d.org .
Beispiele für Gebäude, die unterschiedliche Stockwerkszahlen haben und
bei denen ich damit unzufrieden bin, daß sie derzeit nach dem 'alten'
Schema als Sammlung einzelner Gebäude getaggt sind, befinden sich z.B.
auf diesem Campus (das Hauptgebäude mit Mensa und das Gebäude der
Fakultät 06 im Norden): http://osm.org/go/0...@ggdra-?layers=o

Vielleicht kriegen wir da etwas auf die Beine gestellt, das durchdacht
ist und Akzeptanz unter den Mappern und Renderern finden kann... :)

Gruß,

Martin

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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden Johannes Huesing
M∡rtin Koppenhoefer  [Fri, Nov 05, 2010 at 01:22:20PM 
CET]:
[...]
> 
> ich sehe unsere Datenmodell als ziemlich ungeeignet an, auch vom
> Maßstab, diese Details einzutragen, insbesondere die Seile. Bei
> Widerlagern und Auflagern sehe ich das evtl. schon anders und ich
> würde es schon begrüßen, wenn man mehr abgestimmte Details für Brücken
> hätte.

Du bist da ja Experte, ich musste irgendwann mal lernen, dass in 
bestimmten Plänen Brücken durch ihre Widerlager angegeben sind.

> 
> Das wären allerdings erst mal so Dinge wie den Gesamtumriss der
> Brücke, womit man auch bei getrennter Fahrbahn z.B. angeben könnte,
> dass es doch nur _eine_ Brücke ist, einen abstimmten Weg für den
> Brückennamen, insb. sofern die Straße darüber einen anderen trägt,
> sowie einen Konstruktionstyp und ggf. Tags für Details wie Auflager

Da finde ich ja immer den Wert "yes" verschwendet und gebe auch so
etwas an wie bridge=pontoon.

> (explizit und implizit also als Mengenangabe, könnte man alternativ
> auch mit Feldern angeben (i.d.R. eins weniger)) und Konstruktionstyp
> (z.B. Hängebrücke, Balkenbrücke, Bogenbrücke, Fachwerkbrücke etc.
> vermutlich mit Subtags, also bitte nicht als Haupttag sowas wie
> "vorgespannte Stahlbetonplattenbalkenbrücke"  einführen).
> 
> 
> > Hm, wenn du Martin in dieser Frage beipflichtest, heißt die Lösung für
> > deine Seile wohl building=yes. :-p
> 
> 
> building=rope wäre das analog. 

Ein Seil als Bauwerk anzusehen finde ich fast noch abartiger als eine 
Treppe als Spezialform einer Landstraße zu taggen. 


> Im Bsp. Sony Center war das mit
> building=roof getaggt, nicht yes. Dieser Unterschied ist m.E. nicht
> unbedeutend.
> 

Eben drum, "yes" sollte man nehmen, wenn man es nicht spezifischer 
haben möchte. (Eigentlich wäre "highway=yes" in der Hinsicht klarer
als "highway=road".)

> ja, volle Zustimmung. Das bräuchten wir eigentlich. Sobald wir ins
> 2,5D gehen wollen (mit Höhen) kann es gar nicht ausbleiben, einen
> Umriss für jeden unterschiedlich hohen bzw. mit eigenem Dach
> ausgestatteten Baukörper zu haben. Man könnte den Kirchturm vom Schiff
> trennen, etc.

So wie hier? http://www.openstreetmap.org/browse/way/56007564/

-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden Johannes Huesing
M∡rtin Koppenhoefer  [Fri, Nov 05, 2010 at 01:29:51PM 
CET]:
> Am 5. November 2010 06:27 schrieb Johannes Huesing :
> 
> > Wie man es auch nennt, für die Seile würde ich es nicht verwenden,
> > da ich den Gebäudeteil nur für Knoten und geschlossene Wege
> > definieren, Seile aber als offene Wege modellieren würde.
> 
> 
> Kannst Du das mal ausführen, wie Du Dir das in einem 2,5-D-Modell
> (abgesehen von den genauen Key/Values) vorstellst? 

So weit habe ich nicht gedacht. Die x- und y-Koordinaten der Seile sind 
unabhängig von ihren Höhen interessant, weil man bei drohendem Eisfall
nicht drunter langgehen sollte. (Dann ist allerdings auch das gesamte 
Gelände für Zutritt verboten.) Aber ok, wenn man schon mal dabei ist:

> Wenn man ein
> Linienmodell machen wollte, sollten die Stützen 2 verbundene Nodes
> jeweils übereinander haben, 

Ja, mit passenden height-Tags.

> also einen vertikalen Way (da schonmal
> viel Spaß mit den gegenwärtigen Tools), 

Nur wenn man den Mast in senkrechter Richtung modellieren möchte.  Da
wäre ich aber zufrieden, wenn ein Node mit Tags man_made=tower,
tower:type=communication, height=360 den Mast modellierte. Auf
dieselbe Koordinate würden dann die Anknüpfungspunkte mit
entsprechendem height als einzigem Tag stehen. Bei so etwas wie dem
Sonnensegel am Potsdamer Platz könnte ich mir auch vorstellen,
einzelne Ecken mit einem height-Tag zu versehen.

Mit den gegenwärtigen Tools ist das machbar, macht aber keinen
großen Spaß. Ich habe mal aus einer Laune heraus das Atomium 
eingezeichnet, war aber dann nicht sehr stolz auf das Ergebnis.
Aber solche Gebäude gibt es ja auch nur ein paar Mal. 

-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden Peter Wendorff

Am 05.11.2010 13:22, schrieb M∡rtin Koppenhoefer:

ja, volle Zustimmung. Das bräuchten wir eigentlich. Sobald wir ins
2,5D gehen wollen (mit Höhen) kann es gar nicht ausbleiben, einen
Umriss für jeden unterschiedlich hohen bzw. mit eigenem Dach
ausgestatteten Baukörper zu haben. Man könnte den Kirchturm vom Schiff
trennen, etc.
Am Unicampus Paderborn habe ich dazu ein Schema [1] verwendet und auch 
mit Komzpa (Entwickler von Kothic) abgestimmt.


Bin bisher nicht dazu gekommen, das komplett fertigzumachen und in 'nen 
Proposal-Prozess einzubringen, aber hier passt das vielleicht rein,
und auch wenn das noch auf meiner User-Seite liegt: Kommentare sind 
herzlich willkommen.


Gruß
Peter

[1] http://wiki.openstreetmap.org/wiki/User:Jongleur/MultiLevel

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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden Fabian
so einen aehnlichen vorschlag gabs schonmal in der diskussion wollte es
aber lieber jemandem mit besserem verstaendnis der engl sprache ueberlassen.
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site

M∡rtin Koppenhoefer wrote:
> Am 5. November 2010 13:32 schrieb Fabian :
>> Das erinnert etwas an die "site" relation wo parkplaetze zu
>> einkaufscentren gehoeren.
> 
> 
> Ich bin gegen "site" für Gebäudeteile. Mehrere Gebäudeteile= ein
> Gebäude, (potentiell) mehrere Gebäude = eine site.
> 
> Was man m.E. eher machen könnte wäre einen neuen Typ Relation, der
> systematisch gruppiert, z.B.:
> 
> type=group
> group_type=site / building / river / legal_entity / ...
> 
> 
> Gruß Martin
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de

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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden M∡rtin Koppenhoefer
Am 5. November 2010 13:32 schrieb Fabian :
> Das erinnert etwas an die "site" relation wo parkplaetze zu
> einkaufscentren gehoeren.


Ich bin gegen "site" für Gebäudeteile. Mehrere Gebäudeteile= ein
Gebäude, (potentiell) mehrere Gebäude = eine site.

Was man m.E. eher machen könnte wäre einen neuen Typ Relation, der
systematisch gruppiert, z.B.:

type=group
group_type=site / building / river / legal_entity / ...


Gruß Martin

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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden Fabian

>> Im Ernst: ich denke um die Problematik der information "dies ist *ein*
>> Gebäude" zu umgehen, die es auch immer gibt, wenn Mapper z.B.
>> unterschiedlich hohe Gebäudeteile als separate (wenn auch
>> "verbundene") Polygone mit building=yes taggen, wäre es angebracht,
>> Gebäude und Gebäude*teile* zu trennen - nennen wir es einmal
>> "buildingpart=*".
> 
> 
> ja, volle Zustimmung. Das bräuchten wir eigentlich. Sobald wir ins
> 2,5D gehen wollen (mit Höhen) kann es gar nicht ausbleiben, einen
> Umriss für jeden unterschiedlich hohen bzw. mit eigenem Dach
> ausgestatteten Baukörper zu haben. Man könnte den Kirchturm vom Schiff
> trennen, etc.
> 
Das erinnert etwas an die "site" relation wo parkplaetze zu
einkaufscentren gehoeren. Koennte doch auch an sowas adaptiert werden.
Fuer Gebaeude ueber mehrere Etagen war "site" und "level" bisher
hilfreich. Leider kuemmert sich keiner der großen renderer drum so das
sachen die uebereinander sind auch so angezeigt werden. Im einkaufcenter
der fastfood imbiss unter der pizzaria unter dem Restaurant

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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden M∡rtin Koppenhoefer
Am 5. November 2010 06:27 schrieb Johannes Huesing :

> Wie man es auch nennt, für die Seile würde ich es nicht verwenden,
> da ich den Gebäudeteil nur für Knoten und geschlossene Wege
> definieren, Seile aber als offene Wege modellieren würde.


Kannst Du das mal ausführen, wie Du Dir das in einem 2,5-D-Modell
(abgesehen von den genauen Key/Values) vorstellst? Wenn man ein
Linienmodell machen wollte, sollten die Stützen 2 verbundene Nodes
jeweils übereinander haben, also einen vertikalen Way (da schonmal
viel Spaß mit den gegenwärtigen Tools), so dass man an den oberen Node
(hier der 2. Spaß) ein Seil anschließen kann.

Alternativvorschlag: Umriss einzeichnen und ein externes 3D-Modell
damit verlinken. Format müsste man klären, anbieten würde sich Blender
(opensource), dxf / 3ds (weit verbreitet) es gibt aber natürlich noch
Myaden anderer 3D-Formate (shape, stl, etc.).

Gruß Martin

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


Re: [Talk-de] Gebäude-Mapping

2010-11-05 Diskussionsfäden M∡rtin Koppenhoefer
Am 4. November 2010 22:26 schrieb Martin Simon :
> Am 4. November 2010 20:21 schrieb Johannes Huesing :
>... wäre ich durchaus versucht gewesen,
>> die Betonanker der Spannseile und die Seile selbst zu mappen. Wie aber
>> würde man Seile mit statischem Zweck eintragen, etwa auch bei Hängebrücken?
>> Line hat sich glaube ich nur als Wert zum Schlüssel power eingebürgert.


ich sehe unsere Datenmodell als ziemlich ungeeignet an, auch vom
Maßstab, diese Details einzutragen, insbesondere die Seile. Bei
Widerlagern und Auflagern sehe ich das evtl. schon anders und ich
würde es schon begrüßen, wenn man mehr abgestimmte Details für Brücken
hätte.

Das wären allerdings erst mal so Dinge wie den Gesamtumriss der
Brücke, womit man auch bei getrennter Fahrbahn z.B. angeben könnte,
dass es doch nur _eine_ Brücke ist, einen abstimmten Weg für den
Brückennamen, insb. sofern die Straße darüber einen anderen trägt,
sowie einen Konstruktionstyp und ggf. Tags für Details wie Auflager
(explizit und implizit also als Mengenangabe, könnte man alternativ
auch mit Feldern angeben (i.d.R. eins weniger)) und Konstruktionstyp
(z.B. Hängebrücke, Balkenbrücke, Bogenbrücke, Fachwerkbrücke etc.
vermutlich mit Subtags, also bitte nicht als Haupttag sowas wie
"vorgespannte Stahlbetonplattenbalkenbrücke"  einführen).


> Hm, wenn du Martin in dieser Frage beipflichtest, heißt die Lösung für
> deine Seile wohl building=yes. :-p


building=rope wäre das analog. Im Bsp. Sony Center war das mit
building=roof getaggt, nicht yes. Dieser Unterschied ist m.E. nicht
unbedeutend.


> Im Ernst: ich denke um die Problematik der information "dies ist *ein*
> Gebäude" zu umgehen, die es auch immer gibt, wenn Mapper z.B.
> unterschiedlich hohe Gebäudeteile als separate (wenn auch
> "verbundene") Polygone mit building=yes taggen, wäre es angebracht,
> Gebäude und Gebäude*teile* zu trennen - nennen wir es einmal
> "buildingpart=*".


ja, volle Zustimmung. Das bräuchten wir eigentlich. Sobald wir ins
2,5D gehen wollen (mit Höhen) kann es gar nicht ausbleiben, einen
Umriss für jeden unterschiedlich hohen bzw. mit eigenem Dach
ausgestatteten Baukörper zu haben. Man könnte den Kirchturm vom Schiff
trennen, etc.

Gruß Martin

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


Re: [Talk-de] Gebäude-Mapping

2010-11-04 Diskussionsfäden Johannes Huesing
Martin Simon  [Thu, Nov 04, 2010 at 10:26:17PM CET]:
> Am 4. November 2010 20:21 schrieb Johannes Huesing :
> 
> >> Sehe ich anders. Die Realität wird m.E. ziemlich gut wiedergegeben,
> >
> > *beipflicht*
> >
> > Da wir gerade bei ger nicht so kleinen Details sind. Kürzlich war ich beim
> > Sender Donebach spazieren. Wäre meine Frau nicht dabeigewesen (so fangen
> > glaube ich viele Mapper ihre Sätze an), wäre ich durchaus versucht gewesen,
> > die Betonanker der Spannseile und die Seile selbst zu mappen. Wie aber
> > würde man Seile mit statischem Zweck eintragen, etwa auch bei Hängebrücken?
> > Line hat sich glaube ich nur als Wert zum Schlüssel power eingebürgert.
> 
> Hm, wenn du Martin in dieser Frage beipflichtest, heißt die Lösung für
> deine Seile wohl building=yes. :-p
> 
> SCNR...
> 
> 
> Im Ernst: ich denke um die Problematik der information "dies ist *ein*
> Gebäude" zu umgehen, die es auch immer gibt, wenn Mapper z.B.
> unterschiedlich hohe Gebäudeteile als separate (wenn auch
> "verbundene") Polygone mit building=yes taggen, wäre es angebracht,
> Gebäude und Gebäude*teile* zu trennen - nennen wir es einmal
> "buildingpart=*".

Ich las mal den Vorschlag "element". Damit wäre aber wieder ein 
sehr allgemeiner Begriff für eine sehr spezielle Sache gekapert.

Wie man es auch nennt, für die Seile würde ich es nicht verwenden, 
da ich den Gebäudeteil nur für Knoten und geschlossene Wege
definieren, Seile aber als offene Wege modellieren würde.

-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

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


Re: [Talk-de] Gebäude-Mapping

2010-11-04 Diskussionsfäden Martin Simon
Am 4. November 2010 20:21 schrieb Johannes Huesing :

>> Sehe ich anders. Die Realität wird m.E. ziemlich gut wiedergegeben,
>
> *beipflicht*
>
> Da wir gerade bei ger nicht so kleinen Details sind. Kürzlich war ich beim
> Sender Donebach spazieren. Wäre meine Frau nicht dabeigewesen (so fangen
> glaube ich viele Mapper ihre Sätze an), wäre ich durchaus versucht gewesen,
> die Betonanker der Spannseile und die Seile selbst zu mappen. Wie aber
> würde man Seile mit statischem Zweck eintragen, etwa auch bei Hängebrücken?
> Line hat sich glaube ich nur als Wert zum Schlüssel power eingebürgert.

Hm, wenn du Martin in dieser Frage beipflichtest, heißt die Lösung für
deine Seile wohl building=yes. :-p

SCNR...


Im Ernst: ich denke um die Problematik der information "dies ist *ein*
Gebäude" zu umgehen, die es auch immer gibt, wenn Mapper z.B.
unterschiedlich hohe Gebäudeteile als separate (wenn auch
"verbundene") Polygone mit building=yes taggen, wäre es angebracht,
Gebäude und Gebäude*teile* zu trennen - nennen wir es einmal
"buildingpart=*".
Das Dach des Sony Centers wäre z.B. buildingpart=roof (Dach ohne
darunter liegendes massives Gebäude, also nicht zur Aufstandsfläche
beitragend), die restlichen Bestandteile vielleicht erst einmal
buildingpart=yes.
Das ganze wird dann mit einer Simplen Relation vom typ building
zusammengefasst, die auch das alte building=* Tag enthält für den
Gebäudetyp.

Das hätte mehrere Vorteile: man könnte Gebäude genauer modellieren und
z.B. einzelnen Bauteilen unterschiedliche Basis- und Scheitelhöhen
geben (Dach des Sony Centers), ohne daß die "falsche" Information
aufkommt, es handle sich um eine Sammlung einzelner Gebäude. Dasselbe
gilt für unterschiedliche Stockwerkszahlen, Dachformen, etc.

Renderer, die sich dafür nicht interessieren, können "buildingpart"
einfach genauso zeichnen wie "building" - oder und verlieren dabei im
vergleich zu heute nichts. Die "building"-Relation würde es zudem
erlauben, auch unterteilten Gebäuden Funktionen aus dem Spektrum von
amenity=*, shop=* etc zuzuweisen.

Dieser Gedanke ist mir jetzt schon ein paar mal gekommen, mich würde
interessieren, ob ich der einzige bin, der hierin einen Nutzen sieht.

Gruß,

Martin

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


Re: [Talk-de] Gebäude-Mapping

2010-11-04 Diskussionsfäden Johannes Huesing
M∡rtin Koppenhoefer  [Wed, Nov 03, 2010 at 09:43:42AM 
CET]:
> Am 3. November 2010 09:05 schrieb Johann H. Addicks :
> > Am 03.11.2010 08:13, schrieb Peter Wendorff:
> >
> >> Ich sehe in diesem Fall das Problem nicht.
> >> Okay, man kann das als Gesamtgebäude sehen und das Micromapping ablehnen.
> >> Aber als building=roof (obwohl mir dieser Tag so zum ersten Mal
> >> begegnet) ist es einfach etwas detaillierter gemappt;
> >
> > Das ist eine Glaskuppel OHNE Luftlöcher in der segmentartige Sonnensegel
> > hängen.
> > siehe z.B.
> > http://www.berlin49.de/images/edit_image/image/bvg%20bezirke/sony%20center.JPG
> >
> > sieht zwar toll aus im Mapnik, aber mit der Situation in der Realität hat
> > das wenig zu tun.
> 
> 
> Sehe ich anders. Die Realität wird m.E. ziemlich gut wiedergegeben,

*beipflicht*

Da wir gerade bei ger nicht so kleinen Details sind. Kürzlich war ich beim
Sender Donebach spazieren. Wäre meine Frau nicht dabeigewesen (so fangen
glaube ich viele Mapper ihre Sätze an), wäre ich durchaus versucht gewesen,
die Betonanker der Spannseile und die Seile selbst zu mappen. Wie aber
würde man Seile mit statischem Zweck eintragen, etwa auch bei Hängebrücken? 
Line hat sich glaube ich nur als Wert zum Schlüssel power eingebürgert.

http://de.wikipedia.org/wiki/Sender_Donebach
-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

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


Re: [Talk-de] Gebäude-Mapping

2010-11-03 Diskussionsfäden Rainer Knaepper
wendo...@uni-paderborn.de (Peter Wendorff)  am 03.11.10:

>Wo also ist das Problem, und wieso ist das "Malen statt Mappen"?


Ich sehe dort in Mapnik ein kreisrundes Gebäude, speichenartig umgeben
von 24 etwa spitzdreieckigen Gebäuden, wiederum umgeben von einem
halbkreisförmigen Gebäude.

Wenn da mal nicht explizit für den Renderer getaggt wurde, damit es
schick aussieht.

Btw: Wie mapt man sowas? Haben wir freie, hochauflösende Luftbilder
davon?

Rainer

-- 


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


Re: [Talk-de] Gebäude-Mapping

2010-11-03 Diskussionsfäden M∡rtin Koppenhoefer
Am 3. November 2010 09:05 schrieb Johann H. Addicks :
> Am 03.11.2010 08:13, schrieb Peter Wendorff:
>
>> Ich sehe in diesem Fall das Problem nicht.
>> Okay, man kann das als Gesamtgebäude sehen und das Micromapping ablehnen.
>> Aber als building=roof (obwohl mir dieser Tag so zum ersten Mal
>> begegnet) ist es einfach etwas detaillierter gemappt;
>
> Das ist eine Glaskuppel OHNE Luftlöcher in der segmentartige Sonnensegel
> hängen.
> siehe z.B.
> http://www.berlin49.de/images/edit_image/image/bvg%20bezirke/sony%20center.JPG
>
> sieht zwar toll aus im Mapnik, aber mit der Situation in der Realität hat
> das wenig zu tun.


Sehe ich anders. Die Realität wird m.E. ziemlich gut wiedergegeben,
daher der hohe Wiedererkennungseffekt. Mit Building=roof ist das eine
brauchbare Beschreibung. Klar, es ist eine eher großmaßstäbliche (kl.
Zoom) Abstraktion, der räumliche Fachwerkträger wurde z.B. nicht in
allen Details wiedergegeben ;-). Wenn man das weglassen würde, wäre
m.E. die Darstellung schlechter, d.h. weniger gut zu erkennen und dem
realen Raum weniger angemessen.

Gruß Martin

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


Re: [Talk-de] Gebäude-Mapping

2010-11-03 Diskussionsfäden Peter Wendorff

Am 03.11.2010 09:05, schrieb Johann H. Addicks:

Am 03.11.2010 08:13, schrieb Peter Wendorff:


Ich sehe in diesem Fall das Problem nicht.
Okay, man kann das als Gesamtgebäude sehen und das Micromapping 
ablehnen.

Aber als building=roof (obwohl mir dieser Tag so zum ersten Mal
begegnet) ist es einfach etwas detaillierter gemappt;
Das ist eine Glaskuppel OHNE Luftlöcher in der segmentartige 
Sonnensegel hängen.
siehe z.B. 
http://www.berlin49.de/images/edit_image/image/bvg%20bezirke/sony%20center.JPG

okay, dann nehme ich alles zurück ;)
Falls aber jemand vom Yahoo-WMS abgezeichnet hat, kann ich das aber gut 
verstehen, da sah es sehr korrekt aus.


sieht zwar toll aus im Mapnik, aber mit der Situation in der Realität 
hat das wenig zu tun.
Wie gesagt: in Yahoo nicht zu sehen, danach korrekt abgezeichnet (wenn 
das die Quelle war), also mit lokalem Fachwissen korrigieren ;)
(obwohl das rendering so eigentlich sehr schön ist... - ich würd die 
Sonnenegel vielleicht umtaggen, aber drinlassen, falls es jemand rendern 
möchte)


Gruß
Peter

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


Re: [Talk-de] Gebäude-Mapping

2010-11-03 Diskussionsfäden Johann H. Addicks

Am 03.11.2010 08:13, schrieb Peter Wendorff:


Ich sehe in diesem Fall das Problem nicht.
Okay, man kann das als Gesamtgebäude sehen und das Micromapping ablehnen.
Aber als building=roof (obwohl mir dieser Tag so zum ersten Mal
begegnet) ist es einfach etwas detaillierter gemappt;
Das ist eine Glaskuppel OHNE Luftlöcher in der segmentartige Sonnensegel 
hängen.
siehe z.B. 
http://www.berlin49.de/images/edit_image/image/bvg%20bezirke/sony%20center.JPG


sieht zwar toll aus im Mapnik, aber mit der Situation in der Realität 
hat das wenig zu tun.


-jha-


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


Re: [Talk-de] Gebäude-Mapping

2010-11-03 Diskussionsfäden Peter Wendorff

Am 02.11.2010 23:36, schrieb Johann H. Addicks:

Am 02.11.2010 20:37, schrieb Kay Drangmeister:
Nach einigen Diskussionen wie man Karten mit Layern ansprechender 
gestalten


Danke.
Auch wenn der Ausschnitt natürlich willkürlich gewählt wurde, ich sehe 
da gerade, wie das Dach des Sony-Centers mit seinen eingespannten 
Sonnensegeln nachgemalt wurde.


Mag ja im Mapnik toll ausschauen, aber das ist kein Mapping, das ist 
Malen...

Ich sehe in diesem Fall das Problem nicht.
Okay, man kann das als Gesamtgebäude sehen und das Micromapping ablehnen.
Aber als building=roof (obwohl mir dieser Tag so zum ersten Mal 
begegnet) ist es einfach etwas detaillierter gemappt; und soweit ich das 
mit Satellitenbildern von Yahoo und Google vergleiche, eigentlich 
ziemlich richtig.

Wo also ist das Problem, und wieso ist das "Malen statt Mappen"?

Gruß
Peter


-jha-


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




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