neue Eigenschaften oparl:Location - zoomLevel / isPoi #258
Comments
|
Bei beiden Eigenschaften geht es offenbar vorrangig um die Präsentation. Die Notwendigkeit von Soweit mit |
|
Je nachdem in welchem Kontext die Geodaten zur Drucksache stehen, halte ich einen Zoomlevel für sinnvoll. Es kann sich in einem Fall um einen Flächennutzungsplan handeln, in einem anderen um ein bestimmtes Flurstück. Das Setzen eines Markers entscheidet nicht der Server, sondern der Sachbearbeiter in der Verwaltung. Auf das vorstehende Beispiel bezogen, würde bei der Darstellung eines Flächennutzungsplanes kein Punkt (POI) angezeigt, bei dem Flurstück wäre es schon sinnvoll. Wenn der Server diese Information nicht vorgibt, dann stellt sich die Frage, aufgrund welcher Information ein Client einen Marker anzeigen sollte oder nicht. Beide Merkmale werden in unserer Anwendung vorgehalten. |
Sowohl bei einem Flurstück als auch bei einem Flächennutzungsplan würde Oder geht es darum, dass z.B. für einen Flächennutzungsplan eine Bounding Box (eventuell mit einem Bereich drumherum) angegeben wird, diese aber nicht angezeigt werden soll? Diese Anforderung kann ich nachvollziehen. Dann würde ich sie aber allgemeiner Unabhängig davon halte ich es für sinnvoll, dass Informationen über die Art des Kontexts (hier: Flächennutzungsplan, Flurstück) formuliert werden können. |
|
Ich habe auch das Gefühl, dass hier Angaben gemeint sind, die ausschließlich die Präsentation betreffen. Das einfachste denkbare Location-Objekt ist wohl das, welches als Geometrie nur eine Punkt-Position enthält. Ich denke, es darf Client-Entwicklern überlassen werden, ob und in welcher Art von Karte und mit welchem Kartenmaßstab und welcher Markierung eine solche Position dargestellt wird. Komplexere Geometrien wie z.B. Multipolygone haben eine Ausdehnung. Ein Kartenausschnitt wäre wohl idealerweise so zu wählen, dass (zumindest initial) die gesamte Geometrie zur Anzeige kommt. Bislang glaube ich nicht, dass OParl hiezu bestimmte Vorgaben machen sollte. |
|
Eine optionale Bounding Box wie oben beschrieben ist aus meine Sicht aktuell die optimale Lösung für das eigentliche Problem. Sie kann leicht sowohl auf Server- als auch auf Client-Seite implementiert werden kann und (über-)erfüllt auch die Anforderung von @sterni24 (gegebenenfalls nach etwas Rechnen auf dem Server). Ich werde dies jedenfalls für OpenGovLD vorschlagen und auch den Betreuer des Core Location Vocabulary der EU befragen - das Vokabular erwähnt im Gegensatz zu INSPIRE bisher keine Bounding Box. Auch in Popolo ist bislang keine Bounding Box vorgesehen. |
Das einfachste denkbare Location-Objekt ist wohl das, welches als Geometrie nur eine Punkt-Position enthält. Ich denke, es darf Client-Entwicklern überlassen werden, ob und in welcher Art von Karte und mit welchem Kartenmaßstab und welcher Markierung eine solche Position dargestellt wird. Es geht in der Tat nur um eine Punkt-Position Client-Entwickler wissen allerdings nicht, um welche inhalte es sich bei einer Location handelt und ob ein Marker dargestellt werden soll oder nicht. Unsere Anwender haben hier konkrete Anforderungen, in denen es genau um diese zwei Eigenschaften geht. Das hatte ich oben schon beschrieben. |
|
@sterni24 Ich tue mich noch etwas schwer mit dem Verständnis, welches Problem hier gelöst werden soll. Wenn ich das richtig verstehe, geht es darum, dass das, was eigentlich eine (oder mehrere) Flächen betrifft (Flächennutzungsplan, Flurstück, ...) auf einen Punkt reduziert werden soll. Und weil ein Punkt keine Ausdehnung hat, weiß ein Client nicht, in welchem Karten-Maßstab ein solcher Punkt angezeigt werden soll. Und ob der Punkt mit einem Marker hervorgehoben werden soll oder nicht. Stimmt das? |
|
Exakt! |
|
Ein Punkt ist auch bei millardenfacher Vergrößerung oder Verkleinerung immer noch der selbe Punkt. Es geht also offensichtlich gerade nicht um den Punkt selbst, sondern um seine Umgebung, also den idealerweise anzuzeigenden Kartenausschnitt. |
|
@akuckartz Da sind wir uns ja mal wieder einig! Und dafür benötigen wir den ZoomLevel. |
|
@sterni24 Ja, wir sind uns einig, was das Problem ist. Aber nicht in der Lösung. Ein Zoom Level wird immer von einer bestimmten Ausgabefläche ausgehen. Ein Zoom Level hift deshalb nicht, da dann z.B. bei einer Darstellung auf sehr großem Bildschirm nur ein winziger angezeigter Teil relevant ist. |
|
Ein ZoomLevel bestimmt den Kartenmaßstab. Hier entscheidet sich, ob. z. B. Straßennamen oder sogar Hausnummern angezeigt werden oder nicht. Wenn die von Ihnen erwähnte BoundingBox dem Betrachter einen zu kleinen Ausschnitt präsentiert, kann er doch ohne Probleme in den Vollbildmodus wechseln. Diese Lösung hat sogar google im Portfolio. Siehe |
|
@sterni24 Die Bounding Box garantiert ja gerade, dass der Ausschnitt richtig ist. Deshalb schlage ich die Art Lösung vor, die auch Google verwendet: Bounding Box statt Zoom Level. |
|
@akuckartz Ich weiß nicht, wie Sie das mit einem Punkt schaffen wollen. |
|
@sterni24 Entweder man hat eine quadratische Bounding Box mit Angaben in Längen- und Breitengrad (mit dem POI im Zentrum) oder man hat einen POI, einen Skalierungsfaktor und eine feste Kantenlänge eines Quadrats mit Angaben in einer Anzeigeeinheit (mit dem POI im Zentrum). Zwischen beiden kann man hin- und herrechnen. Die Bounding Box hat den Vorteil, dass damit auch nicht-quadratische Rechtecke angegeben werden können. |
|
Nachdem ich jetzt weiß, dass ich das Problem richtig verstanden habe, bin ich nicht der Meinung, dass die angebotenen Lösungen (ZoomLevel oder zusätzliche Bounding Box) adäquate Lösungen sind. Wenn es z. B. in einer Drucksache um eine Fläche geht, etwa weil der Flächennutzungsplan geändert werden soll, dann ist ein einzelner Punkt keine adäquate Darstellung dafür, egal ob mit oder ohne Marker. Die vorgeschlagenen Lösungen sind nicht dazu geeignet, diesen Mangel zu beheben, sondern helfen lediglich, ihn zu kaschieren. Während ein zusätzliches Bounding Box Attribut mit einer entsprechenden Beschreibung des Zwecks noch inhaltliche Bedeutung hat (räumliche Ausdehnung des örtlichen Bezugs als Rechteck repräsentiert), zielt die ZoomLevel- und Marker-Eigenschaft lediglich auf die Darstellungsebene ab. Ausgerechnet hier soll OParl Vorgaben zur Darstellung bestimmter Inhalte machen, während wir das sonst an keiner anderen Stelle tun. Wir geben ja auch nicht an, mit welcher Linien- und Fülfarbe ein Polygon dargestellt werden soll, ob es überhaupt eine Füllbfarbe oder Konturlinie geben muss, etc. - Wir sagen nichts darüber aus, ob es einen Kartenhintergrund geben muss und wenn ja welchen. Und ob die Karte vom Nutzer gezoomt werden soll. Betrachte ich die Anforderung, eine Geoposition ohne Marker darzustellen, aus Nutzersicht, dann glaube ich nicht, dass mir ein "leerer" Kartenausschnitt (auf dem nur eine Grundkarte zu sehen ist) sehr viel weiter helfen wird. Zur Bounding Box : Aus adäquaten Geodaten (also solchen, die eine räumliche Ausdehnung haben) eine solche Bounding Box zu ermitteln ist eine Kleinigkeit für einen Client. Dazu braucht es keine Daten vom Server. Dass ein System-Betreiber eine Bounding Box liefern kann, wenn ansonsten nur ein Punkt möglich wäre, halte ich für unwahrscheinlich. |
Ausgerechnet hier soll OParl Vorgaben zur Darstellung bestimmter Inhalte machen, während wir das sonst an keiner anderen Stelle tun.Für die grafische Darstellung von Karten, ob nun Ausschnitt oder Vollansicht braucht es einen Maßstab. Da wir es hier nicht mit vorgefertigen Objekten, wie PDF-Dateien mit fester Größe z. B. DIN A4 zu tun haben, sondern oparl:Location-Objekte zur Laufzeit dargestellt werden, ist die Angabe eines Maßstabes erforderlich.
Betrachte ich die Anforderung, eine Geoposition ohne Marker darzustellen, aus Nutzersicht, dann glaube ich nicht, dass mir ein "leerer" Kartenausschnitt (auf dem nur eine Grundkarte zu sehen ist) sehr viel weiter helfen wird.Das ist eine konkrete, bereits umgesetzte Anforderung unserer Anwender. Die Bewertung, ob da jemandem mit weiter geholfen wird, ist an dieser Stelle unerheblich. Dass ein System-Betreiber eine Bounding Box liefern kann, wenn ansonsten nur ein Punkt möglich wäre, halte ich für unwahrscheinlich.Genau das werden wir tun! Da es hier offensichtlich keine Akzeptanz und auch keine weiteren RIS-Hersteller gibt, die sich zur Zeit mit diesem Thema auseinander setzen, werden wir den OParl-Standard für uns um zunächst 2 Merkmale erweitern:
|
sterni24
changed the title
|
@sterni24 Wie passt dies:
denn hiermit zusammen:
? |
Genau das ist seit Jahrhunderten die weitaus überwiegende Art und Weise wie Karten verwendet werden. |
|
... und das wird vermutlich auch noch eine Weile so bleiben. @akuckartz Wie das in dem Kommentar davor zusammen passt, erfahren Sie, wenn Sie die Beiträge noch einmal im Kontext studieren. |
|
Hier als Vergleich eine Papier-Landkarte heranzuziehen, führt uns kaum weiter. Aber wenn es denn gewollt ist: Auch mit einer Papier-Landkarte ist es nicht einfach, über ein Artefakt zu sprechen, das auf der Karte nicht eingezeichnet ist. Was Sie hier abbilden wollen, erinnert mich an einen öffentlich installierten Stadtplan, bei dem die Markierung für "Sie sind hier" vergessen wurde. |
|
Bei Wahl geeigneter Ausschnitte sind die relevanten Artefakte in Karten häufig auch dann zu erkennen, wenn sie nicht hervorgehoben werden. Das ist auch bei Kartenanzeigen im Internet eine übliche Vorgehensweise. Und je nach Artefakt und Karte kann eine besondere Hervorhebung sogar eher störend sein. Ein öffentlich installierter Stadtplan ohne "Standort"-Markierung ist grundsätzlich besser als kein Stadtplan. Was herstellerspezifische Eigenschaften betrifft so überlege ich für OpenGovLD eine Anforderung wonach herstellerspezifische Eigenschaften nicht zulässig sind, wenn stattdessen in der Spezifikation enthaltene Eigenschaften verwendet werden können. OpenGovLD#71 Der Teufel steckt aber auch hier im Detail. |
Kein Stadtplan steht hier ja glücklicherwise nicht zur Diskussion. |
Prima, aber dann wird eine Eigenschaft benötigt, mit der man den Ausschnitt angeben kann. Der Name ist zweitrangig. Möglichkeiten sind |
|
Da hier offensichtlich völlig unterschiedliche Denkweisen vorliegen und wir auf keinen gemeinsamen Nenner kommen, schließe ich das Thema an dieser Stelle. |
Die EIgenschaft
zoomLevelwird benötigt, damit dem Betrachter schon ein entsprechend voreingestellter Kartenausschnitt angezeigt werden kann.Die Angabe
isPoi(vormals mapPin) legt fest, ob eine Nadel angezeigt wird oder nicht.The text was updated successfully, but these errors were encountered: