Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access
Mateusz Konieczny via talk wrote: > > I just added some example at https://wiki.openstreetmap.org/wiki/Key:access > and improved existing one. > > Review, and improving edits (or comments here) would be welcomed. I disagree with moving the Table Of Contents far from the top of the page. I use it for quick access to the individual chapters, and am having a hard time finding it quickly. I think that especially on a page as long and complex as this one, it's important that the TOC is at the top of the page, right before the first header. https://wiki.openstreetmap.org/w/index.php?title=Key:access=1994648=1994635 See also Wikipedia MOS:LEAD: | | As a general rule of thumb, a lead section should contain no | more than four well-composed paragraphs [...] -- Arne Johannessen <https://arne.johannessen.de/> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access
On 25 May 2020, at 01:45, Mateusz Konieczny via talk wrote: > May 25, 2020, 00:36 by a...@thaw.de: >> >> I would argue that non-gated driveways are often closer to >> access=destination than they are to access=private. >> >> According to the wiki, private requires individual permission, which I can't >> give to the mailman / delivery person, but I still want them to make their >> deliveries on my doorstep. > I would describe delivery part as > > "I have given individual permission to delivery person by requesting delivery" Not all deliveries are actively requested, and the delivery person can't know if you requested it or not. Therefore, access=private as a _default_ for driveways seems wrong to me. > Random person driving to my house and trying to sell me random items would > not be covered by such permission and unwanted and violating access rules, > right? > > Such peddler would be allowed by access=destination (any non-transit > traffic allowed). Exactly. In the jurisdictions I'm familiar with, such traffic is in fact generally allowed on driveways. However, some driveways are behind a locked gate or clearly signed as "private / no trespassing" (which is legally equivalent in some jurisdictions). Such cases should qualify for an _explicit_ access=private tag. Delivery to your doorstep might then be impossible, unless there's like a bell at the gate that can be used by the delivery person to obtain individual permission. So, access=private for driveways is not necessarily wrong, it's but probably somewhat rare. Your new language about this on the access=* page seems fine to me: https://wiki.openstreetmap.org/w/index.php?title=Key:access=1994851#Road_with_restricted_access FWIW, I'm less happy with the current state of the access=private page. But I'm not sure if consensus exists to clarify it. -- Arne Johannessen <https://wiki.openstreetmap.org/wiki/User:Arne_Johannessen> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Examples at https://wiki.openstreetmap.org/wiki/Key:access
Mateusz Konieczny via talk wrote: > > From quick review I am unable to remember any actually existing > access restriction that would not be taggable. The default motor_vehicle=* of Norwegian forest roads [1] by law [2] depends on physical criteria such as tracktype=*, surface=*, smoothness=*, width=*. The law makes this a judgement call in each and every case. [3] I'm not aware of a useful way to tag this restriction, so I personally like to simply add those physical tags and leave the problem for interested data consumers to decide for themselves. A clear consensus on the tagging of forest roads does not seem to currently exist in the Norwegian OSM community. [1] I use "forest road" as a loose translation of "veg i utmark", meaning something like "road not in towns or farmland". In OSM, they could be tagged as highway=track, service, residential, unclassified; depending on the circumstances. [2] https://www.regjeringen.no/en/dokumenter/motor-traffic-on-uncultivated-land-and-i/id173402/ [3] in Norwegian, the government's interpretation of the law: https://www.regjeringen.no/no/dokument/dep/kld/rundskriv/1996/t-196-motorferdsel-i-utmark/4/id278805/ > [nuclear power plants vs. residential driveways] > > Is access=private supposed to be incorrect in either case? I would argue that non-gated driveways are often closer to access=destination than they are to access=private. According to the wiki, private requires individual permission, which I can't give to the mailman / delivery person, but I still want them to make their deliveries on my doorstep. -- Arne Johannessen <https://wiki.openstreetmap.org/wiki/User:Arne_Johannessen> ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Karten-Projektion Merkator
Martin Koppenhoefer <dieterdre...@gmail.com> wrote: > > > Google hat afaik nur das Slippymap-Prinzip erfunden, die Projektion ist von > Merkator. Die von Google erfundene Variante der Mercator-Abbildung hat im Gegensatz zum "echten" Mercator Formverzerrungen (ist dafür aber billiger zu rechnen). Die Nordseeinsel Juist wird zum Beispiel rund 20 cm breiter dargestellt, als sie tatsächlich ist... -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karten-Projektion Merkator
Markus <liste12a4...@gmx.de> wrote: > > "Most of OSM, including the main tiling system, > uses a spherical Mercator projection. " Ja, erfunden von Google. Besondere Merkmale: - einfach zu rechnen - geringe Formverzerrungen, sieht "bekannt" aus - riesige Größenverzerrungen (z. B. Grönland/Afrika) - die Welt wird zum Quadrat > Warum machen wir das so? Weil sie einfach ist, weit verbreitet und somit kompatibel ist und die Nachteile nicht zu groß sind. Insbesondere sind die Größenverzerrungen der Mercator-Abbildung in mittleren und größeren Maßstäben speziell für unsere Slippy Map kein Problem. > Welche Alternativen gibt es? Die interessante Frage wäre, welche /sinnvollen/ Alternativen es gibt und wie sich das umsetzen ließe. Kartennetzentwürfe sind Versuche, die unregelmäßig runde Erdkugel in einer flachen Ebene abzubilden. Dabei muss zwangsläufig irgendwas verzerrt werden. Der Mercator-Entwurf hat im Randbereich z. B. wortwörtlich unendlich große Flächenverzerrungen, weshalb er niemals den kompletten Planeten abbilden kann. Je nach Kartenzweck sind mal die einen, mal die anderen Verzerrungen akzeptabel oder sogar erwünscht. <http://www.boehmwanderkarten.de/kartographie/netze/world_bonne_45.jpg> zeigt beispielsweise den Bonneschen Herz-Entwurf. Trotz der dubiosen Form wird der Planet komplett abgebildet (sogar flächentreu). Die großen Formverzerrungen machen dieses Netz aber in der Praxis untauglich. Für eine Slippy Map könnte es bedeuten, dass z. B. in San Francisco die Golden Gate Bridge rechts der Innenstadt gezeichnet würde – verwirrend für jeden, der Ortskunde hat. Ähnliche Probleme ergeben sich bei den meisten interessanten Entwürfen. Benötigt würde für die Slippy Map also evtl. eine Lösung, für kleine Maßstäbe ein anderes Kartennetz zu wählen als für große Maßstäbe, und auf irgendeinem Zoom-Level umzuschalten. An der Hochschule Karlsruhe hörte ich diesen Sommer Ideen dazu, aber ich weiß nicht, ob sich daraus irgendwas ergeben hat. Andererseits ist es heutzutage dank leistungsstarker Desktop-Rechner vielleicht möglich, das Rendern vom Server auf den Browser zu verlagern, wie der schon genannte Mapzen-Post es macht. Dann könnte der Browser natürlich jeden beliebigen Netzentwurf rechnen und z. B. in San Francisco die gesamte Karte einfach so drehen, dass Norden oben ist (wie es der Mapzen-Post auch demonstriert). Ob all das dann aber mit jedem Client einschließlich Smartphones performant funktioniert, ist fraglich. <http://www.boehmwanderkarten.de/kartographie/is_netze.html> hat eine Liste zahlreicher Kartennetze mit bunten Bildern und ein paar Anmerkungen zur Tauglichkeit für bestimmte Kartenzwecke. > Welche OSM-Karten nutzen welche Alternative? > Warum? > > Wie machen das Google? Wikipedia? andere grosse Anbieter? > Was sind die jeweiligen Vorteile? In Slippy Maps kenne ich nur Google-Mercator, von vereinzelten Experimenten abgesehen. > Spezialfrage: > Was bedeutet "equidistant cylindrical projection"? sog. Plattkarte, siehe <http://www.boehmwanderkarten.de/kartographie/is_netze_cyl.html#cylinder_abstandstreu> "WGS Geographic" in JOSM > wann wie warum macht das Sinn? Eigentlich nie, wegen der starken Verzerrungen und weil eben heutzutage bessere Abbildungen auch nicht teuer zu rechnen sind. -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzumstellung - verschollene Mapper
DarkAngel wrote: ich habe hier gerade den Fall eines Mappers, der für seinen Arbeitgeber OSM-Daten eingepflegt hat. [...] [...] Rechtlich kann ich nicht beurteilen, da der User ja im Auftrag seines Arbeitgebers gehandelt hat. Das deutsche Urheberrecht ist nicht übertragbar, weswegen dem Arbeitgeber i. d. R. konkludent ein (einfaches oder ausschließliches) Nutzungsrecht an erzeugten Werken eingeräumt wird. Das heißt, im vorliegenden Fall ist _anscheinend_ effektiv der Arbeitgeber der Lizenzgeber der Daten gegenüber OSM und kann daher über ihre Weiterverwendung im Projekt entscheiden. IANAL etc. Arne -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzumstellung - verschollene Mapper
Falk Zscheile wrote: [...] Der Arbeitgeber hätte die Daten natürlich auch nach der Lizenzumstellung in der neuen Datenbank. Falk Zscheile wrote: Unterstellen wir, das der Arbeitgeber das Nutzungsrecht hat. Wie jetzt weiter? [...] Na, zum Beispiel so: DarkAngel wrote: Technisch sollte es kein Problem sein die Mailadresse zu reaktivieren bzw. im Account zu ändern. [...] Oder übersehe ich was? -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
Heiko Jacobs wrote: Nein, diese Möglichkeit gibt es nicht, da man PD doch nur dann anklicken und abschicken kann, wenn man auch ODBL akzeptiert hat, oder? Du kannst ja PD auch auf andere Weise deklarieren. Michael schrieb, Florian habe das im Wiki entsprechend geschrieben. (Zur Rechtsgültigkeit einer Checkbox oder eines Wiki-Eintrags lasse ich mich nicht aus. Theoretisch könntest Du aber auch bei jedem Edit ins Changeset schreiben license=PD.) -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Alle Jahre wieder - Flyer-Neuauflage
Frederik Ramm wrote: Ziemlich verbluefft musste ich anhand eines Blicks in meine Unterlagen feststellen, dass wir mittlerweile 70.000 Stueck davon gedruckt und weitgehend verteilt haben. Nicht schlecht! Heh, wow. :) Waere es zum Beispiel Zeit, den Fokus im Text etwas weg vom GPS-Geraet und hin zum Luftbild zu legen, eventuell sogar das kleine dreiteilige GPS-Track-Bild durch irgendeinen Potlatch-Screenshot mit Luftbild ersetzen, a la 1. vom Luftbild abmalen, 2. vor Ort Details notieren, 3. Karte fertig? Die Luftbilder in meiner Gegend (liegt allerdings nicht in D) sind häufig nicht lagegenau und müssen immer erst anhand von GPS-Tracks richtig positioniert werden (meist ~ 10 m Versatz). Daher habe ich den Eindruck, GPS wird noch für einige Zeit die Hauptstütze von OSM bleiben. Hinzu kommt der rechtliche Aspekt: Wir wollen ja nicht den Eindruck erwecken, dass man einfach von jedem beliebigen Luftbild tracen und das Resultat nach OSM übernehmen darf. Dass eigene GPS-Tracks da unproblematisch sind, leuchtet viel eher ein, meine ich. Sollte man vielleicht einen OpenCycleMap- oder anderen thematischen Kartenausschnitt zeigen statt 2x Mapnik-Standard? Vielleicht den deutschen Stil statt des englischen nehmen? Klingt beides nach einer guten Idee. Müsste man mal ein Beispiel von ansehen, um zu beurteilen, ob es im Layout aussieht. Bleiben wir beim Sie, obwohl wir jeden, der einen Account anlegt oder seine Nase auf einem Stammtisch zeigt, sofort duzen? Ich würde sagen: du (kleingeschrieben) Interessanter Vergleich: im Apple Store wird jeder Besucher sofort und ohne Nachfrage geduzt, egal welches Alter. Das verwundert manch Älteren, kommt aber meiner Beobachtung nach auch bei Senioren ganz gut an. Die deutschlandweite Version will ich aber weiterhin ueber die Geofabrik kostenlos verteilen. Toll, vielen Dank! Schöne Grüße, Arne -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nutzung alter Karten
André Joost wrote: Am 01.09.10 10:27, schrieb Norbert Kück: am 01.09.2010 09:20 schrieb Jan Tappenbeck: Die Kartendarstellung entspricht der einer Flurkarte 1:1000 und wurde auch von einem Herrn vom Katasteramt seiner Zeit 1907-1911 gezeichnet. Kann mir einer sagen ob dieses Material für uns verwertbar ist ? Wenn der Herr seit mehr als 70 Jahren verblichen ist: Ja. Siehe: http://bundesrecht.juris.de/urhg/__64.html Genau. Es sei denn, der Herr wäre nicht namentlich bekannt -- dann würden die 70 Jahre ab der Veröffentlichung der Karte zählen. Viele Karten geben ja nur den Herausgeber (das Amt) an, auf die dürfte diese Regelung zutreffen. Wenn er das als Angestellter des Katasteramtes gemacht hat, liegt das Urheberrecht mit Sicherheit beim Amt und nicht beim Zeichner. Und das Amt ist bestimmt noch nicht verblichen... Weder kann ein Amt ein Urheberrecht haben noch kann es verbleichen. Lediglich das Nutzungsrecht liegt beim Amt. -- Arne Johannessen http://wiki.openstreetmap.org/wiki/User:Arne_Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nutzung alter Karten
Jan Tappenbeck wrote: Die Kartendarstellung entspricht der einer Flurkarte 1:1000 und wurde auch von einem Herrn vom Katasteramt seiner Zeit 1907-1911 gezeichnet. Kann mir einer sagen ob dieses Material für uns verwertbar ist ? Mit Material meinst Du sicherlich nicht die Katasterkarten selbst, sondern die enthaltenen Geodaten. Großer Unterschied! Zum Recht des Datenbankherstellers: In Bezug auf diese stellen die Katasterkarten eine (analoge) Datenbank dar. Selbst wenn das Datenbankrecht rückwirkend gelten sollte (weiß ich gerade nicht), wäre die Schutzfrist nach § 87d aber längst abgelaufen. Das Bestehen eines sui-generis-Rechts kann also klar verneint werden. Zum eigentlichen Urheberrecht: Bei einer Katasterkarte im Maßstab 1:1000 findet üblicherweise gar keine oder keine nennenswerte Generalisierung statt. Es handelt sich lediglich um eine nicht wertende Darstellung von Fakten, aber typischerweise nicht um eine geistige Schöpfung. Ein Urheberrecht an den dargestellten Fakten kann also nach § 2 Abs. 2 auch verneint werden. (Dass Landes-Vermessungsgesetze darüber hinaus anwendbar sein könnten, glaube ich nicht, kann es aber auch nicht ausschließen.) Ich würde also sagen: ja, die Geodaten können wir verwerten. Ich bin jedoch kein Anwalt... -- Arne Johannessen http://wiki.openstreetmap.org/wiki/User:Arne_Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
Christian Wagner wrote: Lighthouses: Die Unterscheidung ob ein Leuctturm aktiv oder nicht ist, ist doch eigentlich schon durch das tag light=yes gegeben. Klar. Gerade Leuchttürme sind, anders als küstennahe Kirchtürme, Schornsteine etc., auf jeden Fall an von See aus einsehbarer Stelle gebaut, also immer eine, nautisch relevante landmark. Einige Bauformen von Leuchttürmen sind vor dem Hintergrund fast unsichtbar oder es ist nicht offensichtlich, dass es sich um die Position eines nautischen Feuers handelt. Beispiele wären das Hochhaus in Travemünde oder das Feuer auf Lyø, Dänemark. Ok, vielleicht fällt so was gar nicht unter man_made=lighthouse. Mit immer wäre ich trotzdem vorsichtig, aber per Default sind Leuchttürme natürlich i. d. R. schon Landmarken, das stimmt schon. Auch ohne extra Tag. Man_made=lighthouse mit fakultativ light=yes (und falls vorhanden alle anderen nautischen tags ist doch eigentlich völlig ausreichend. Ja. Tiefenangaben: [...] Sind die Daten erstmal in der Karte dann werden sie (aus Bequemlichkeit) auch genutzt. Genau. Tiefenangaben in Flachwassergebieten sind daher in OSM möglicherweise eine Gefahr für die Sicherheit der Seefahrt. [...] Auch kann ich ja nicht davon ausgehen daß nicht zwischen zwei Tiefenmesspunkten nicht noch eine Untiefe existiert. [...] Genau das ist nämlich das Hauptproblem. Die ganzen Messungenauigkeiten, Gezeiten etc. sind wohl irgendwie lösbar, aber eine auch nur annähernd vollständige Abdeckung des Grunds schafft OSM prinzipbedingt nicht. Und wo es untief ist, kann das eine Gefahr darstellen. Was z. B. hingegen problemlos geht: Geringste Tiefen eines Fahrwassers etc. angeben. Das können wir leicht halbwegs genau messen und hilft schon sauviel. Viele Grüße, Arne PS. bin derzeit offline -- Arne Johannessen http://wiki.openstreetmap.org/wiki/User:Arne_Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Tagging Seamarks
Hi Bernhard, thanks for your reply. This message has become longer than I initially expected, as I added some general thoughts of mine. Please do feel free to ignore those and concentrate on open questions. :) Bernhard R. Fischer wrote: [...] Also FT puts just an overlay on top of the Openstreetmap map but Openseamap completely renders a seamap with focus on seamap features. Not sure what you're referring to. I mean, http://www.freietonne.de/seekarte/ and http://openseamap.org/ are both just overlays on top of the standard Mapnik OSM rendering, right? [...] This is the reason why I personally favor Openseamap more than FT. In addition, FT is focused more on inland waterways. Personally, I favour neither one of those projects. I'd just like to add some marine data to OSM, and don't fancy doing it twice (once per tagging scheme). Besides, there are clear technological issues with this kind of redundancy. I'm also thinking about writing a new renderer (or renderer style) for marine data in OSM, and find the existing documentation of the tagging schemes in use less than optimal for that purpose. A further question for me is what is official and what is private? Both of those tagging schemes are similar although the structure is different, as you mentioned. As far as I can see, the similarities pretty much end with the fact that they both can be used for buoys and beacons and stuff. Sure, some of the strings look the same, but because of the different structure this merely adds to the confusion. Speaking of the structure: I also have the impression, that the OSeaM scheme views all of their tags as non-optional, resulting in a true proliferation of tags even for otherwise simple objects. But I may be wrong on that. The Wiki appears to be silent on the matter. Anyway, what I meant by official is something like the Map Features -- a single go-to-page with most relevant links to the consensus of the OSM community as far as tagging is concerned, enabling newbies to just go ahead and start working. With private I meant a tagging scheme that is not used in OSM except by a certain group of people for their own purposes. But as I said, I may have misunderstood the earlier discussion on this matter on [talk-de]. And, what is IMO much more important, the Openseamap scheme is already rendered on OpenSeamap which is not true for the other one and I stick with the opinion of the Openseamp guys: a seamap should be rendered different than a street map because different objects are important. Sorry, I'm not a member of either project and hence am not very well versed in their technology. Which renderer are you presently referring to? I mean, as far as I know, both projects have their own slippy maps on their home pages (see above), but at this point neither of them really looks different than a street map because they both use the default Mapnik rendering style as base. But then again, there also appear to be existing solutions to export marine data from OSM to embedded systems (hand-held GPSs, chart plotters etc.), so the renderer landscape could be said to be a bit more diverse than just consisting of a few slippy maps. Perhaps you're referring to one of these exported OSM displays..? I agree with you BTW: a marine map should eventually be rendered different from land maps, no matter whether the sea or inland waterways are depicted. However, as an IT guy I prefer the Openseamp scheme to the offical one because it is more modular from a technical point of view. How is it more modular? How would modularity be useful in a practical sense? Can you provide an example or use case? Being an IT guy myself, I think that maintainability (i. e. ease-of-use) of source code is very important. With tags being OSM's source code, this makes me a big fan of the pragmatism that generally governs the OSM community's approach to finding and agreeing upon new tags. That's also why I'd like to see OSM tags for marine data that are conceptually similar to OSM tags for land data. And that's also why I have every expectation that we'll eventually arrive at such a tagging scheme, however it may look. :) Thus, I hope that people out there do not still ignore the Openseamap scheme. After all, I translated it into English ;) Ah, thanks for doing that. Hopefully it will facilitate some discussion. Regarding S-57: I think what they mean is that they orient on the S-57 schemes in respect to which attributes exist on which objects. Yes, maybe that's what happened. But S-57 is very convoluted and very specific to ENCs, even just far as the object attributes are concerned. OSM can be a lot more flexible. We should make use of that flexibility. I for one think it would be a mistake to have another data format's constraints carry over into OSM. Cheers, Arne -- Arne Johannessen ___ talk mailing list talk
Re: [OSM-talk] Tagging Seamarks
Malcolm Herring wrote: Andreas Labres wrote: Continuing dispute between the two groups I was suggesting that a state of peaceful co-existence can be achieved - Our editors will not alter or remove tags that are not ours, and hopefully this will be reciprocated. Not realistic IMHO. At least one of the editors currently in use (perhaps even several) is GUI-only and apparently operates only on one of those tagging schemes. As a direct result, nodes with tags like this have been observed on several occasions: buoy:colour=red seamark:buoy_whatever:colour=green The thing is that this so-called peaceful co-existence leads to one group not reading the other group's tags when editing. This kind of error is prone to happen over and over again and creates sever inconsistency issues for any third party attempting to create a neutral renderer or editor. I see agreeing on one single, official OSM tagging scheme as the only realistic long-term solution. and become productive (get nice renderers, get nice editors etc.). Nice renderers and editors do not just materialize - they have to be written by the members of the sub-projects. True, it looks like the peaceful co-existence is a necessary situation for the time being. Ideally though, everyone would work towards discussing and creating a single scheme. This is the crux of the matter - after having spend considerable time developing those tools, based on a particular set of tag definitions, any later suggestion that we should change them is not going to receive an enthusiastic response! Depends, I'd say. Perhaps the tools are written in a way that embraces such changes. I don't know, I didn't really look at the source of any of the editors. As far as users are concerned, editors remove the need to manually edit tags, thus no knowledge of the tagging scheme is necessary. As to the question of which scheme to use - choose the editor that will place your work onto the map overlay that you want to see it on. In such a situation, the map overlays could just as well operate a database of their own, as there wouldn't be any point in having their data in OSM. Or am I mistaken? PS: there has been a recent update of the OpenSeaMap JOSM plugin (toms). This is now in the OSM repository, so it can be installed using the JOSM Preferences dialogue. The accompanying Mappaint styles will shortly be installable by this method also. Sounds intriguing! I looked at it half a year ago, when it was still very much pre-alpha work. I'll be sure to check it out again, thanks for the heads-up. Cheers, Arne -- Arne Johannessen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging Seamarks
Bernhard R. Fischer wrote: For a long time now I am interested in tagging seamarks.(short version) Same here. I always knew that there wasn't anything near to consensus about much of anything on that front though, with a lot of bad blood in the German OSM community, which is one of the reasons why I shied away from getting involved until about now. Very frustrating situation indeed. Now I found out that there are two comparable but different and competing tagging schemes: * http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging * http://wiki.openstreetmap.org/wiki/Lights_Data_Model The first one is used by freietonne.de the second one by openseamap.org. Consequently, there exist two disjoint marine maps. Right. New information (at least, new to some, including me) has surfaced on the German [Talk-de] OSM mailing list that says (paraphrasing) the first mentioned is the one and only official proposal (incidentally also used by FT, FreieTonne.de). The second link you mentioned is part of the scheme of the other project (OSeaM, openseamap.org). So it would appear that we actually have * one official proposal, currently under discussion (also used by FT) * one private scheme, with private tags (exclusively used by OSeaM) Now, the thing is I'm not really sure about this assessment. What I wrote above is my current understanding of the situation, which may be wrong. I'd appreciate input from FT or OSeaM project members on this matter, or really from anyone at all! This is extremely frustrating! Computers do not care about attribute names and we shouldn't also as long as both schemes fulfill the same requirements. This is not just a naming issue. The tagging concepts of the schemes are rather different (contrary to what has been alleged somewhere on the Wiki). There seems to be a lot of half knowledge and smattering among some of those who wrote on the Wiki on marine topics in the past, which of course is very conductive to misunderstandings. I believe this is part of what fuelled the conflicts between FT and OSeaM back then (but I was an observer in those conflicts only, so what do I know :) ). Anyway, one thing I find particularly remarkable is that on just about every one of the Wiki pages, someone wrote something about that this tagging scheme followed IHO standard S-57, and how important and cool that would be, while actually (and thankfully), none of those schemes even come close to S-57. S-57 is basically a soon-to-be-obsolete, proprietary and binary file format, so following it wouldn't really make a lot of sense for OSM. Not sure why so many people wrote that. Perhaps someone on this list is able to enlighten me? Cheers, Arne -- Arne Johannessen ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Tiefenangabe als Name
Falk Zscheile wrote: Am 17. August 2010 07:17 schrieb Mario Salvini salv...@t-online.de: Am 17. August 2010 03:21 schrieb Andreas Labres l...@lab.at: On 11.08.10 21:24, Jan Jesse wrote: water:depth= Welche water:* oder welche *:depth gibt's sonst noch? water:*=* -- andere Attribute des Wassers (spontan fallen mir nur Sachen wie Farbe oder Salzgehalt ein, die ich jetzt nicht sonderlich sinnvoll fände; aber vielleicht hat ja jemand was konkretes) depth bezieht sicher aber schon immer auf Wasser, deshalb könnte man den Key in der Tat auch gleich depth=* nennen. Interessanter als die Frage nach dem Namen des Tags ist aber die Frage, was dann damit getaggt wird. Einen einzelnen Node mit Tiefenangabe finde ich z. B. weniger sinnvoll als eine bekannte Mindesttiefe in einem Fahrwasser, einer Durchfahrt oder einer sonstigen Wasserfläche. Auf diese Weise lassen sich mit recht wenig Aufwand sinnvoll für nautische Zwecke nutzbare Tiefendaten eines ganzen Gewässernetzes in OSM einführen. Einzelnodes mit depth=3.7 sagen mir dagegen nichts darüber, ob ich dazwischen sicher durchfahren kann oder nicht. Dies scheint mir Teil des Gedankenproblems hinsichtlich water:depth vs. seamark:depth in diesem Thread zu sein. Maximaltiefen könnten für nicht-nautische Zwecke ebenfalls sinnvoll sein. depth könnte beispielsweise auch angeben, wie weit die Wasseroberfläche eines Sees unter normal Null liegt (Nur als Gedankenspiel.) Nein. *Tiefe* bezieht sich immer auf die Entfernung eines Gewässergrunds zur Wasseroberfläche. Bei Wasserflächen in Depressionen hat die Oberfläche eine negative *Höhe* unter dem Meer. Habe ich jedenfalls anders noch nie gesehen. Auf jeden Fall werden Tiefen in Richtung Erdmittelpunkt größer, und Höhen werden in Richtung Weltraum größer. (Die Tiefen in Binnenseen werden in topographischen (Land-)Karten aber auch manchmal als Höhen angegeben, in Metern über NN, bzw. der jeweiligen Bezugsfläche der Landesvermessung. Das kann verwirren.) Was mir noch fehlt ist das Bezugssystem, auf das sich die Wassertiefe Höhe bezieht, also auf welches normal Null sich die Wassertiefe aber auch die Höhe von Bergen etc. bezieht. Meiner Ansicht nach hat OSM gegenwärtig keine Probleme mit unterschiedlichen Bezugsflächen. Die Unterschiede zwischen den sinnvollen Bezugssystemen liegen nämlich typischerweise im Bereich der Messungenauigkeit. Vor die Wahl von einheitlichen Höhenbezugsflächen in OSM sollte meiner Ansicht nach die Suche nach entsprechenden Use-Cases gestellt werden. -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Leuchttuerme und andere Landmarken (ex: Unterscheidung)
Mario Salvini wrote: Am 16. August 2010 23:35 schrieb Arne Johannessen a...@thaw.de: [...] Das Tage würde ich dann aber vielleicht anders nennen, denn die IHO definiert ausdrücklich (eigentlich durchaus logisch): landmark ungleich seamark Wie wäre es mit einfach nur: landmark=* (z. B. landmark=yes oder landmark=prominent) Im Proposal http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging#Landmarks ist das Konzept für landmark zwar ein etwas anderes. [...] stimmt. im Proposal wird dabei mehr auf die S57 bezug genommen, die mit dem Akronym LNDMRK (Landmark) und dem Attribut CATLMK (Category of Landmerk) die Möglichkeit bietet Landmarken zu beschreiben. Aber vermutlich habt ihr recht und wir können das Dank OSM und der schon vorhandenen TAGgin-Kultur anders die gleichen Sachen erfassen (z.B. für cemetry, winmill, tower, etc..) Ja, also wir haben ja hier den Sonderfall, zu einer existierenden Landkarte (OSM) nautisch-hydrographische Daten hinzufügen zu wollen. S-100/S-101, S-57 und S-4 (früher M-4) sind alle für Daten bzw. Karten vorgesehen, die von vornherein nur zur Navigation gedacht sind -- Seekarten eben. Die IHO-Standards sind sicherlich auch für uns sehr nützlich. Für bereits in OSM konzeptuell vorhandene Objekte wie Gebäude, Brücken, Straßen etc. sollten sie aber nicht angewandt werden bzw. höchstens in Bezug auf den nautischen Wert dieser Objekte. Andreas Labres wrote: Bei Landmarken ist aber eine Kennzeichung das ist eine Landmarke schon relevant. Das Ding muß von See gut zu sehen sein, es hilft Dir nix, wenn der Kirchturm in einer Senke steht und davor ein Hügel mit Wald Dir die Sicht verdeckt. Oder blöd, wenn diese Kirche grade keinen weithin sichtbaren Kirchturm hat. Mario Salvini wrote: Mit landmark=yes/promentent/whatever könnt ich mich persönlich auf jeden Fall durchaus anfreunden. :) Dass ein derartiges Tag konsensfähig seien könnte, scheint der bisherigen Diskussion hier jedenfalls zu entnehmen zu sein. Das könnten wir vielleicht auch mal im Wiki irgendwie dokumentieren? Ich habe da leider noch keinen Account und bin mir hinsichtlich der Gepflogenheiten unsicher. Ich hätte z. B. Skrupel, einfach so das Proposal zu bearbeiten. Wie geht man hier am besten vor? M∡rtin Koppenhoefer wrote: Am 16. August 2010 23:35 schrieb Arne Johannessen a...@thaw.de: (Mögliches Problem: Landmarken für die Luftfahrt?) wie wärs mit landmark=nautic? Wenn es natürlich von Land, See und aus der Luft ein Landmark ist (dürfte öfters vorkommen), dann bräuchte man dafür evtl. einen extra Wert (sowas wie landmark=nautic/aerial/all od. yes). nautical hieße das auf Englisch. Gegenpart: aeronautical. Ein Bisschen lang, funktioniert aber vom Prinzip her prima. Der Fall beide würde wohl von landmark=nautical;aeronautical abgedeckt (wegen mir auch landmark=all), der Fall weiß nicht genau von landmark=yes. Rolf Meyerhof wrote: Warum nicht landmark=navigation ? wenn es für Land Luft und See gelten soll? Ginge vom Prinzip her auch (gefällt mir nicht besonders, ist aber nur Geschmacksache). Mario Salvini wrote: vielleicht im zweifelsfalle ein landmark:naval=* oder landmark:aerial=* ? naval heißt wörtlich Flotten- (also militärischer Bezug), passt daher nicht. Dass wir hier einen extra Namensraum brauchen, glaube ich auch nicht. Dass eine Landmarke auffällig ist, können wir ebenso gut über conspicuous=yes o. ä. erfassen. (Wenn Du fließend in S-57 denkst: das entspräche dem Attribut CONVIS=1) Mario Salvini wrote: Bei den Baken haben wir ja im Grunde ein ähnliches Problem mit Luft unf Wasser ;) Haben wir? Ich kenne in der Luftfahrt an Beacons nur die ABNs, die das bekannte Blinksignal auf Flugplätzen von sich geben (normal W/W in Deutschland, W/G in Nordamerika). Das kann man prima genau wie Feuer (Lichter) auf Leuchttürmen und Tonnen taggen (wird in Seekarten auch so gemacht). Die Widmung der Lichter (z. B. Aero. / CATLIT=5 etc.) bräuchten wir eigentlich auch noch ... aber das kann wohl warten. Grüße, Arne -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] S-57 in OSM
Mario Salvini wrote: [http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging] also der erste Link zum Proposal war der offizielle bzw. öffentliche We der Community Seezeichen zu erfassen. Die anderen Links sind entweder Inhalte der einen oder der anderen überwiegend deutschen Fraktionen (ich glaube das bekommt die restliche Welt garnicht so mit) Aha, danke für die Klarstellung. In den letzten Tagen wurde ja auch schon ein wenig weiter am Wiki gearbeitet; damit und mit den laufenden Diskussionen zum Thema wird mir nun klarer, was wozu gehört. Ich spreche jetzt mal zur zum Proposal, über die anderen Links können sich die jeweiligen Gruppen äußern. Mir persönlich wäre eine klare Bezeichnung im Link (z.B. OSeaM/Bake-Schema.. etc. dass es sich um Projekt-Unterseiten handelt wichtig, weil sonst wirklich bald kein Aussehnstehender mehr durchblickt... +1 Ich habe jedenfalls bis vor wenigen Tagen da überhaupt nicht durchgeblickt. Das Proposal orientiert sich am Schema S57 Dies, also die Nähe des Proposals zu S-57, kann ich überhaupt nicht feststellen. Das ist aber, wie schon angedeutet, auch Sehr Gut So (mit großen Anfangsbuchstaben). Auf [OSM-talk] fiel auch gerade der Begriff S-57 (im Thread Tagging Seamarks). Ich will die Stränge jetzt nicht redundant führen, daher gerade nur so viel: S-57 ist ein eigentlich veraltetes, binäres, äußerst unflexibles Datenformat, dessen Methodik bei der Kategorisierung und Auszeichnung von Geodaten mit der Technik und den Werten von OSM grundsätzlich inkompatibel ist. S-57 zu folgen, ist also *nicht* anzustreben. Dennoch kann natürlich S-57 zusammen mit dem Nachfolger S-100/S-101 und dem IHO-Standard für Papierseekarten S-4 (ehemals M-4) zusammen mit dessen Anhängen INT 1 (Karte 1), INT 2 und INT 3 als extrem nützliches Nachschlagewerk zu nautischen Geodaten dienen. Ich nehme an, dies ist auch das, was mit den zahlreichen Referenzen zu S-57 gemeint sein soll? Darauf bezieht sich meine Nachfrage in diesem Thread. Die Formulierung im Wiki wäre in dem Fall entsprechend zu verbessern. Völlig unabhängig vom Erzeugen der nautischen Tags in OSM ist übrigens der Export von OSM in ein Datenformat, welches in Kartenplottern und anderen Geräten an Bord direkt verwendet werden kann. Exportieren von OSM nach S-57 ist grundsätzlich immer möglich, man vergleiche hier die bestehenden Export-Funktionen von OSM nach Garmin-Formaten. Da braucht man (sollte man?) bei der Gestaltung der Tags keine Rücksicht drauf nehmen. ... und versucht die doch sehr kryptischen und eher maschinenorientierten Scheibschemata in eine menschlich lesbare und vor allem in eine einfache, intuitive OSM-STruktur zu wandeln. In der Tat finde ich das Proposal alles in allem sehr lesbar, einfach und weitgehend auch intuitiv, jedenfalls meiner Ansicht nach. Ob das gelingt oder nich sollte da diskutiert werden. OK, ich besorge mir dann endlich mal einen Wiki-Account und mache da ein paar Anmerkungen auf der Diskussions-Seite. Allerdings hielte ich sehr viel davon, nicht alle nautischen Themen auf einer einzigen Seite zu diskutieren (wird sicher sonst bald sehr unübersichtlich), sondern die Themen aufzusplitten. Anbieten würde sich hier die Einteilung der INT 1. Grüße, Arne -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] S-57 in OSM
Mario Salvini wrote: das Proposal bekommt jetzt eh mal ein Clean-up. Ja, ich habe gelesen, der Wiki-User Cbm will da aktiv werden. Liest der hier mit? (Bist Du das am Ende selbst?) Welche Einteiung würdest du denn nach INT-1 vorschlagen? Die sich aus ihr selbst ergebende sieht auf den ersten Blick schon verdammt gut brauchbar aus. Das BSH hat sich damals bei der Erstherstellung der INT 1 für die IHO einen Haufen Arbeit gemacht, darauf können wir sicher gut aufbauen. Ich würde es mit einer Wiki-Seite je Kapitel (also je Buchstabe) probieren. Die Abschnitte innerhalb Kapiteln (z. B. P20-P23 für Richtfeuer, P30-P31 für Leitfeuer etc.) würde ich überwiegend auf die selbe Wiki-Seite mit jeweiligen Überschriften setzen wollen. Das gehört ja halt irgendwie doch zum Hauptthema Leuchtfeuer und kann gut zusammen diskutiert werden. Nicht alle Kapitel, Abschnitte und Zeichen machen für OSM Sinn. Einige können vorerst ignoriert und später durch Verweise auf die Map Features ersetzt werden. Für die übrigen, interessanten Kapitel würde ich dann je eine Wiki-Seite vorsehen: F - Wasserbauten, Häfen I - Tiefen K - Felsen, Wracks, Schifffahrtshindernisse L - Offshore-Anlagen [Windfarmen, Plattformen, Kabel, Pipelines etc.] M - Schifffahrtswege N - Gebiete, Grenzen P - Leuchtfeuer Q - Tonnen, Baken Die weitere Unterteilung auf den jeweiligen Seiten können wir quasi aus der INT 1 abschreiben. Eintragen der einzelnen Symbole bzw. Tags dann je nach Bedarf. Wir brauchen auch noch einzelne weitere Themen wie z. B. Brücken (D20-D29) und Landmarken (E1-E2, Rest siehe Map Features). Für die könnten auch schon mal die jeweiligen Seiten (z. B. D Bauten und E Landmarken) erzeugt werden, oder man schreibt sie erst auf eine sonstiges-Seite. Der Vorteil beim Einteilen nach INT 1 (Zeichenerklärung für Seekarten) ist vor allem die einfache Referenz. Da sind dann hübsche Abbildungen der aus den Seekarten vertrauten Kartenzeichen drin, und eben eine gute Einteilung sowie treffende englische Begriffe (die fürs Taggen nützlich sein können). Der Kartograph/Mapper findet überall Verweise zur IHO S-4 (früher M-4) mit weiterem nautischen Hintergrundwissen. Der mit S-57 vertraute Programmierer findet im Anhang D der S-57 eine Cross-Reference zur INT 1, und zwar auch in deren Einteilung. Und: die INT 1 ist leicht verfügbar. Wer mal einen BR- oder SKS-Schein gemacht hat, findet typischerweise noch eine gedruckte Ausgabe der Karte 1 (INT 1) in der Schublade. Das Ding gibt's auch günstig im Buchhandel, und es existiert auch in einigen Sprachen im Netz zum kostenlosen Download: Dänisch + Englisch: ftp://ftp2.kms.dk/download/soekortret/publikationer/kort1.pdf Französisch + Englisch: http://www.iho-ohi.net/iho_pubs/standard/S-4/INT1_FR_Ed.4.pdf Amerikanisch (etwas älter): http://www.nauticalcharts.noaa.gov/mcd/chartno1.htm Die Kapitel-Einteilung ist auf der jeweils vorletzten Seite im PDF bzw. auf dem Rücken des gedruckten Hefts zu sehen, oder im Inhaltsverzeichnis. Letzten Endes kommt es auf die Einteilung nicht unbedingt an. Aber die INT 1 drängt sich auf, ist praktisch und macht für uns Sinn, meiner Ansicht nach. Grüße, Arne -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Toppzeichen S-57 in OSM
Falk Zscheile wrote: Am 18. August 2010 00:09 schrieb Andreas Labres l...@lab.at: [...] (warum man z.B. Topzeichen angeben muß/soll(?), wenn die sich eh aus der Klassifikation ergeben, sehe ich grade nicht... gibt's da lokale Diskrepanzen?), [...] Ja, die gibt es. Das internationale Schema der IALA wird nicht überall angewendet, und nicht alle Arten von Zeichen sind überhaupt in dem Schema erfasst. Ich auch nicht. Im Prinzip müsste es ausreichen anzugeben ob ein Topzeichen auf der Tonne vorhanden ist oder nicht. Für solche Zeichen, die dem IALA-Schema entsprechen, kann der Renderer ein Default für die Form und Farbe des Toppzeichens kennen und braucht keine weiteren Infos als ja oder nein nicht. Aber es gibt eben auch andere Zeichen. Ob das dann auch noch bei Tonnen am einmündenden/abzweigenden Fahrwasser funktioniert dürfte eher ein Problem des Renderers als eines des Taggings sein. Kreuzungen sind unproblematisch, im Gegensatz zu allen möglichen Arten von nationalen und privaten Toppzeichen (Tafeln, Flaggen, Klobürsten, Fische und was nicht alles). Einen Tag für die Spezifikation von Toppzeichen-Formen zu haben, ist somit unumgänglich. Für IALA-Zeichen kann ein Tag für die Toppzeichen-Form aber evtl. wegfallen, weil dort ein Default-Wert bekannt ist. Ebenso sollte der Renderer als Default für die *Farbe* des Toppzeichens einfach die (Haupt-)Farbe der Tonne annehmen. Aber es gibt Ausnahmen, für die brauchen wir ein Tag. Beispiel (ohne mich auf die Tag-Namen festzulegen): * buoy=safe_water impliziert: topmark=no, colour=red;white, striped=vertical * buoy=safe_water mit topmark=yes ist gleichbedeutend mit topmark=sphere * buoy=safe_water mit topmark=sphere impliziert: colour:topmark=red Um eine normale Mitteltonne zu taggen, reicht dann ein einfaches buoy=safe_water, topmark=yes/no aus. Wenn aber jetzt ein Depp ein falsches Toppzeichen montiert oder die Sonne die rote Farbe zu weiß verbleicht oder das Toppzeichen zur Hälfte abgefallen ist (alles schon gesehen), dann können wir auch diesen IALA-Spezialfall trotzdem abbilden. So viel zur Notwendigkeit. Wie jetzt die Tags konkret heißen, ist im Prinzip egal (obwohl ich natürlich eine Meinung habe). -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
M∡rtin Koppenhoefer wrote: Am 15. August 2010 22:39 schrieb Olaf Hannemann ohannem...@gmx.de: Warum habt ihr bei den Leuchttürmen alle seamark=landmark tags in seamark=lighthouse umgewandelt? [...] ehrlich gesagt halte ich beides für redundant und daher überflüssig. Wenn man Leuchttürme als landmarks rendern will, kann man das genauso gut mit man_made=lighthouse tun. Einen Extratag braucht man dafür nicht. Sehe ich auch so. Evtl. könnte es ggf. sinnvoll sein, aktive und alte Leuchttürme zu unterscheiden, indem die aktiven zusätzlich den seamark-tag bekommen (wenn Leuchttürme wovon ich als Landratte ausgehe, Seezeichen sind, die für die Navigation relevant sind). Üblicherweise in OSM machen wir das allerdings sonst über disused. Ein Leuchtturm am Wasser hat normal immer seinen normalen Wert als Landmarke (also als sichtbarer Turm). Dazu reicht man_made=lighthouse. Ein aktiver Leuchtturm zeichnet sich schlicht durch das Licht aus, ein besonderer disused-Tag ist daher aus nautischer Sicht nicht nötig (vielleicht aber aus kulturhistorischer Sicht oder was auch immer interessant). Papierseekarten zeigen gelöschte Leuchttürme meist mit der gleichen Signatur wie sonstige Türme. Gelegentlich tragen die dann Namen wie etwa Falshöft (alter Leuchtturm). Bei aktiven Leuchttürmen ignorieren Papierkarten jedoch meist den Wert als Landmarke und zeigen nur die Lichterscheinung. Nur ausnahmsweise zeigen Abbildungen ausgewählte Leuchttürme als Landmarke. seamark=landmark - wenn seamarks wie der Name sagt Seezeichen bedeutet (andere Diskussionen hier), macht keinen Sinn. Sinn machte es durchaus -- Leuchttürme und andere nautische Landmarken können als feste Seezeichen betrachtet werden. Aber wie Du schon sagtest, ist hinsichtlich des Werts als Landmarke ein einziges Tag ausreichend, und ausgehend von den Map Features ist hier man_made=lighthouse der erste Kandidat. Grüße, Arne -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
Mario Salvini wrote: seamark=* soll bedeuten, dass da haptisch und tatsächlich ein Gegenstand ist, welcher für einen Schiffs- oder Bootsführer von Bedeutung sein kann. Gerade bei Anfahrten von See spielt dabei auch die Skyline bzw. die Topologie der Küste eine wichtige Rolle. Somit kann es also schon sinnig sein einem Hochhaus oder einem markanten Klippe, einem Funkmast oder eben auch einen (egal aktiv oder nicht) Leuchtturm ein seamark=landmark zu geben. Nochmal frisch in der S-4 nachgeschlagen habend (B-340), wird mir klar, dass Mario Recht hat. Ein derartiges Tag wäre schon mehr als nur ein Renderer-Hint. Der Renderer kann ja nicht wissen, welche Objekte an der Küste tatsächlich prominent zu sehen sind (z. B. abhängig vom Hintergrund, Relief, Farbe etc.). Das ist eigentlich keine kartographische Generalisierung, sondern eine nautische Bewertung als Kartengrundlage. Das Tage würde ich dann aber vielleicht anders nennen, denn die IHO definiert ausdrücklich (eigentlich durchaus logisch): landmark ungleich seamark Wie wäre es mit einfach nur: landmark=* (z. B. landmark=yes oder landmark=prominent) Im Proposal http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging#Landmarks ist das Konzept für landmark zwar ein etwas anderes. Für die meisten der dort genannten Arten von Landmarken sollten aber sowieso andere (nicht-nautische) Tags gesetzt werden (z. B. landuse=cemetery), wodurch ein gleichlautendes nautisches Tag (wie landmark=cemetery) dann sowieso redundant wäre. Das seamark=landmark ist ebenfalls redundant und fiele weg, und das landmark-Tag ist dann schön erweiterbar mit Werten wie landmark=conspicuous für besonders auffällige Objekte usw. (Mögliches Problem: Landmarken für die Luftfahrt?) Leuchttürme sind allerdings von Natur aus mal mindestens Landmarken, weswegen ich für man_made=lighthouse dann den Default-Wert landmark=yes vorschlagen würde. Meinungen? Grüße, Arne http://www.iho-ohi.net/iho_pubs/IHO_Download.htm#special -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel: freiwillige Zustimmung ab jetzt moeglich
Ulf Möller wrote: Am 14.08.2010 22:52, schrieb Guenther Meyer: Hat die Foundation keinen Juristen, der sowas mal klaeren kann? und was ist da bisher rausgekommen? keine konkrete Aussage? Siehe http://wiki.openstreetmap.org/wiki/Open_Data_License/Closed_Issues#Features_touched_by_multiple_contributors.2C_not_all_of_whom_sign_up_to_new_terms Die dortige Antwort des Anwalts scheint aber gar nicht die dort gestellte Frage zu beantworten. Und keines von beiden scheint die Fragen von Heiko und Günther zu beantworten: Guenther Meyer wrote on 13 August at 08:14: Am Freitag 13 August 2010, 01:37:09 schrieb Heiko Jacobs: Ich habe die Tage versucht, eine offizielle Begründung dafür zu finden, dass Daten gelöscht werden *müssen*. [...] das wuerde mich auch mal interessieren: Muss wirklich jeder zustimmen, und bei Nichtzustimmung etwas entfernt werden? [...] Gute Frage. Der Konsens scheint ja zu sein, dass CC-BY-SA sowieso unsere Daten nicht schützt. Was genau spräche also dagegen, in einem Rechtssystem, das weder Fakten noch Datenbanken schützt (USA?), das komplette Planet-File einfach unter die ODBL zu stellen und fertig? OK, nicht ganz die feine Art (höflich formuliert), aber was spricht rechtlich dagegen? -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel: freiwillige Zustimmung ab jetzt moeglich
M∡rtin Koppenhoefer wrote: Am 15. August 2010 18:56 schrieb Arne Johannessen a...@thaw.de: OK, nicht ganz die feine Art (höflich formuliert), aber was spricht rechtlich dagegen? rechtlich hätte man lediglich eine kleine Unsicherheit, weil man nicht genau weiss, ob die CC-BY-SA von irgendeinem Gericht vielleicht doch als ausreichend erachtet wird, das zu untersagen. Vor Gericht und auf hoher See... schon klar. Der Punkt ist aber genau der von Dir genannte: moralisch ist das doch völlig haltlos, in einem Projekt wie dem unseren mit solchen Methoden zu kommen. Sehe ich grundsätzlich ganz genauso, wie zuvor schon angedeutet. Danke für Deine Klarstellung! Der Schaden wäre da vermutlich größer als die Daten komplett zu löschen ;-) Sicher. Grüße, Arne -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel: freiwillige Zustimmung ab jetzt moeglich
Frederik Ramm wrote: On 08/15/2010 07:08 PM, Ulf Möller wrote: Der Konsens scheint ja zu sein, dass CC-BY-SA sowieso unsere Daten nicht schützt. In den USA höchstwahrscheinlich nicht, in anderen Ländern wahrscheinlich schon. Ist das wirklich so eine deutliche USA/nicht-USA-Unterscheidung? Nö, aber darauf kommt es auch nicht an, wenn ein Schutz auch ohne die Lizenz bestünde (wie es etwa in der EU i. A. über das Datenbankrecht der Fall ist). Grüße, Arne -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
Mario Salvini wrote: Am 15. August 2010 19:03 schrieb Rolf Meyerhof r...@meyerhof-net.de: Ich komme auf Dich zu um einen Termin festzulegen. Hier über die Liste zu posten bringt wirkliche keine Fortschritte. wozu immer Termin zum runden Tisch? Wenn OseaM gemeinsamen Konsens anstrebt, müsste man sich einfach den Diskussionen in der OSM-Wiki stellen und nicht einfach imemr im kleinen Kreise irgendwas setzen und da einfach reinhaken. +1 -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterscheidung (war Tiefenangabe alsName)
Olaf Hannemann wrote: Daher hier noch einmal meine dringensten Fragen mit der Bitte auf ehrliche Antwort. [...] Wenn es sich um ernsthafte, sachliche Fragen handelt, dann gib doch bitte bei Gelegenheit (wann auch immer) mal einen Kontext dazu. So einfach dahingestapelt kann ich mit diesen Fragen jedenfalls wenig anfangen. Noch einmal kurz zur nächsten drängenden Frage warum ich die FT Tags nicht render. Wenn ich sie rendern würde, bräuchte ich kein eigenes Tagging-Schema. Wie darf ich das verstehen? Dein eigenes Tagging-Schema (ist dies das OSeaM-Datenmodell?) verwendest Du, um zu vermeiden, die FT Tags rendern zu müssen..? Klingt für mich jetzt sehr danach, als sei Dein eigenes Schema nur Taggen für den Renderer. Aber vielleicht habe ich ja einfach keine Ahnung, wovon Du gerade sprichst. :) Da ich keine eigene Datenbank habe, sondern direkt aus der OSM-Datenbank meine Karten erstelle, bin ich darauf angewiesen, dass die Syntax einigermaßen schlüssig ist. Dies bedeutet z.B. , dass der Name Tag auch den Namen enthält. Dies stelle ich nämlich so auch eins zu eins auf der Karte dar. Wenn dort allerdings etwas wie Tonne rot,grün oder gemessen am *.*.* steht, sieht das wirklich blöd aus. Das sind ja auch falsche Inhalte. Wenn Du diese renderst, wird sicher bald jemand kommen und das Problem beheben (den Namen korrigieren). Ignorierst Du statt dessen das fehlerhafte Tag komplett, wird das Problem niemandem je auffallen und der Fehler bleibt drin. Fehler *müssen* gerendert werden, sonst fallen sie niemandem auf (OK, außer vielleicht zufällig irgendwann mal einem Mapper im Editor). Tipp: Ignoriert doch einfach alle seamark:* Tags, sowie ich auch die anderen ignoriere. Also alles, was mit seamark: anfängt, ist privat für Olaf? ;-) Wenn ihr das gleiche tut, gibt es keine weiteren Probleme. buoy:colour=red seamark:buoy_whatever:colour=green Wie genau ist Dein Plan, um solche und ähnliche Konsistenzprobleme zu vermeiden? Grüße, Arne -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Stephan Wolff wrote: Am 03.08.2010 17:04, schrieb Heiko Eckenreiter: Das ist korrekt. Eine Wassertiefe ist nur zum Zeitpunkt der Messung vor Ort brauchbar. ... Was hier fehlt ist die geeignete Bezugsebene, ohne die eine Tiefenangabe ohne Wert ist. Die natürliche Bezugsebene wird (von Tidengewässern abgesehen) meist der mittlere Wasserspiegel sein. Nun, alle Meeresflächen sind ja Tidengewässer. Nur in wenigen Ausnahmefällen ist der Tidenhub so gering (Ostsee: 1-2 Dezimeter), dass der mittlere Wasserstand als Bezug für Nautische Tiefen verwendet wird. Gut brauchbar sind Tiefenangaben in einer Karte dann, wenn ich ohne Probleme aus den Kartenangaben auf die ungefähre tatsächliche Wassertiefe zu einem bestimmten Zeitpunkt schließen kann. Auf Ostsee und Binnen ist das trivial, an den meisten anderen Orten braucht man zwangsläufig Gezeitentabellen o. ä., die angeben, wann die Tide wie hoch über (oder unter) der Kartenangabe steht. Gezeitentabellen beziehen sich normalerweise ungefähr auf den niedrigsten Wasserstand. Nur, wenn Tiefen in OSM sich ebenfalls etwa auf den niedrigsten Wasserstand beziehen, kann ich anhand der Gezeitentabelle die tatsächliche Wassertiefe dort vorhersagen. In OSM-Karten gerenderte Tiefen auf See sollten sich also i. d. R. nicht auf den mittleren, sondern ebenfalls ungefähr auf den niedrigsten Wasserstand beziehen. (Im Detail gibt es da extreme örtliche Unterschiede, aber für OSM dürfte bis auf weiteres dieses ungefähr ungefähr genau genug sein. :) Diskussionen um LAT vs. MLWS, MnNW etc. brauchen wir also erst mal nicht zu führen.) Die Begriffe unbrauchbar und ohne Wert finde ich hier seltsam. Es gibt viele mögliche Anwender dieser Daten: [...] Für eine Gruppe mag eine Tiefenangabe zu ungenau und unzuverlässig sein, für viele andere ist die Angabe hilfreich und hinreichend genau. Die rohen, nicht rechnerisch reduzierten Tiefenmessungen sind gut vergleichbar mit den GPS-Tracks, die Dir JOSM Co. aus der Datenbank holen. Es gibt sicherlich auch Gruppen, denen die Tracks allein für ihre Zwecke ausreichen, die also gar keine Karte brauchen. Um die Tracks aber ernsthaft verwenden zu können, etwa zur Kartenherstellung, braucht man eine Menge Metadaten (z. B. ist es ein Weg, was für einer, asphaltiert oder nicht, Radfahren erlaubt etc.). Genau so braucht man -- wie schon diskutiert -- auch für die rohen Tiefenmessungen einen Haufen Metadaten, um wirklich sinnvolle Erkenntnisse daraus zu gewinnen. Um also die zuvor in diesem Thread genannten Tags aufzugreifen: water:depth=* ist eher was nur für Mapper seamark:depth=* wäre was für den Renderer Ebenfalls wie GPS-Tracks gehören massenhaft erfasste rohe Tiefenmessungen meiner Ansicht nach nicht in die OSM-Datenbank, sondern in eine externe Datenbank. Im Augenblick kann aber von massenhaft noch keine Rede sein, deshalb habe ich zunächst gar nichts gegen water:depth=*. Mittelfristig wäre zu überlegen, welche Art von Tiefenangaben am ehesten in OSM erfasst und -- ganz wichtig! -- nachgeführt werden kann. Grüße, Arne -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] S-57 in OSM (ex: name für Se ezeichen)
Markus wrote: Aber wir achten darauf, dass der Namensraum seamark: mit der IHO-S-57 übereinstimmt. Die S-57 ist die internationale Norm zur Bezeichnung von nautischen Objekten in Seekarten. [...] [...] Es gibt weltweit kein besseres und einheitlichers Schema als die S-57. [...] Ja, also darüber zerbreche ich mir schon seit Monaten den Kopf ... Ich möchte jetzt niemanden hier mit der Geschichte von S-57 langweilen. Aber es dürfte ja auch unumstritten sein, dass die hier zitierten Aussagen über S-57 eigentlich so nicht ganz richtig sind. Dass die folgenden Wiki-Seiten über das Tagging von Seezeichen etc. (zum Glück!) wenig bis gar nichts mit S-57 zu tun haben, ist jedenfalls offensichtlich. http://wiki.openstreetmap.org/wiki/Proposed_features/marine-tagging http://wiki.openstreetmap.org/wiki/DE:Buoy_Data_Model http://wiki.openstreetmap.org/wiki/DE:Beacon_Data_Model http://wiki.openstreetmap.org/wiki/DE:Lights_Data_Model http://wiki.openstreetmap.org/wiki/DE:Harbour http://wiki.openstreetmap.org/wiki/DE:FreieTonne/Symbole Die oben (etwas aus dem Zusammenhang gerissenen) zitierten Aussagen nehme ich daher zum Anlass, endlich mal nachzufragen, was mit diesen und den im Wiki zu findenden Verweisen auf S-57 eigentlich wirklich gemeint ist? Gefunden habe ich übrigens auch folgende Wiki-Seite, deren OSM-Tags offenbar den Mnemoics bzw. Akronymen aus S-57 entsprechen sollen. Auch diese Seite folgt aber offensichtlich nicht dem Konzept von S-57. Was steckt dahinter? http://wiki.openstreetmap.org/wiki/DE:Bake/S-57 Wäre nett, wenn mich jemand aufklären könnte. Schöne Grüße, Arne (PS: Antworten bitte an talk-de. TIA.) -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiefenangabe als Name
Florian Gross wrote: Deiner Logik nach muß man jetzt auch noch in die Karten reinschreiben, daß man trotz Karte sein Hirn benutzen muß? Dass man das muss, würde mich jedenfalls nicht wundern, nachdem ich vor Jahren folgendes Verkehrszeichen an einigen Straßen in England entdeckt habe. ;-) http://dev.thaw.de/images/Think!.pdf Ansonsten kenne ich aber übrigens tatsächlich auch Karten, die den Benutzer mit derartigen Randangaben belustigen. :) Es wird hier aber sicher niemanden überraschen, dass diese Karten US-amerikanischer Herkunft sind. -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-legal-talk] ODbL: Produced Works other than maps
Frederik Ramm wrote: Arne Johannessen wrote: Note that just rendering the OSM database in PNG format doesn't necessarily create a Produced Work. We have to be careful about the definition of database here. According to the legal definition of database which has been quoted here often enough, any PNG file made from OSM data would qualify as a database, which would render the whole concept of a Produced Work totally useless for OSM. Right. I, too, have been struggling for a while with the Produced Work definition. Eventually I considered section 4.4 (c) ODBL and came to reconcile myself to neglect the difference because it seems not to be relevant in most practical cases. Thus we have agreed that we are willing to consider a PNG file to be a Produced Work unless - and I don't find the specific wording on the Wiki right now but I think there was something like this - someone creates the file specially with the purpose of transporting the database through it. Ah, thanks -- the community guidelines had escaped me. Hm, re-reading the Produced Work guideline I have to say my joy is less than full. :) It seems to not satisfy the 'principle of legal clarity' (?? -- Normenklarheit), as it shouldn't be hard to create a PNG or SVG image that is both fit and 'intended for the extraction of the original data,' without the image necessarily looking like it. It might be kind of difficult to infer the creator's state of mind from just looking at the image (or even its source, for that matter)... Of course, the advantage is the language's conciseness makes it easy to apply by those who want to reuse the database, for better or worse. In that light, I fail to see the difference between a PNG image that represents a list of bakeries in London (which you and Andy would say clearly is a derived database or a substantial excerpt) and a PNG image with a map of London and little bread symbols where there's a bakery (which we do not want to be a derived database nor a substantial excerpt, Again, the distribution format you choose has no influence at all on the database right issues involved. How many bakeries are there in London? Without bothering to count, I'd say Greater London surely has a lot more than 100, while The City probably has less. (A hundred is the limit for 'not Substantial' according to the community guideline for the meaning of Substantial.) If we're talking a Significant portion here, it definitely is a Derived Database in both cases (list and PNG). If we're talking a portion being not Significant, neither the ODBL nor the EU directive restrict your rights and you are free to do whatever you like with the database excerpts anyway. or else the whole ODbL Produced Works idea would fall over and be useless So far I have yet to discover its actual use. Pointers are appreciated. :) I mean, I can imagine cases where the spatial data content of a derived work isn't really significant. I have a tea box in my kitchen that has a nautical chart printed on its outside, overlaid with reproduced paintings of major lighthouses. The map is just in the background, used for illustration if you like, not for spatial orientation. This is what the Produced Work thing might have meant: Cases where the database's contents appear outside the database theme's domain. Another possible example might be a CG movie flying through a virtual 3D version of London, generated exclusively from OSM. The movie clearly isn't a database, as its geospatial content elements aren't individually accessible, yet it clearly has been derived from a substantial portion of OSM. I think the ODBL would require the 3rd dimension (the altitude information not currently present in OSM) to be released share-alike in this case (under section 4.2). - for example we could not mix our map with data licensed under another license). Wouldn't that be more a case of a Collective Database? Cheers, Arne -- Arne Johannessen ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-de] Rendern von Seezeichen und Editor
Falk Zscheile wrote: Am 19. Februar 2010 20:53 schrieb Arne Johannessen a...@thaw.de: Falk Zscheile wrote: [...] Weiteres Beispiel: durch normale Abnutzung erlangen die Toppzeichen auf Backbord- und Steuerbordtonnen in Dänemark gerne schon mal die Form eines Balls. [...] Und Du bist der Meinung, dies müsse ohne wenn und aber in die Karte? :) Das habe ich nie behauptet. Die OSM-*Datenbank* sollte aber an sich in der Lage sein, auch solche temporären Zustände wiederzugeben, wenn jemand meint, die taggen zu müssen (was andere in diesem Thread vorgeschlagen haben, nicht ich). Nur dazu braucht man eben etwas feinere Möglichkeiten, als die bisherigen GUI-Editoren das ermöglichen. Von Hand in JOSM geht natürlich alles, wird aber evtl. vom nächsten User mit einem GUI- Editor nicht berücksichtigt und überschrieben, warum jetzt auch immer. Deshalb mag ich Christians Vorschlag mit den Vorlagen. Meine Meinung nach sprechen verschiedene Aspekte dagegen. Zum einen ist eine Seekarte keine normale topografische Karte, sondern eine Darstellung von Verkehrszeichen. [...] Ja klar. [...] In der Regel wird die Schifffahrtsverwaltung also schneller mit der Korrektur sein als der Maper mit dem Verzeichnen des Fehlers. Zumal es nicht so viele Seefahrende Maper gibt. Aus hauptsächlich diesem Grund halte ich nicht viel davon, von Anfang an Abweichungen zu taggen. Sich bei Tonnen also auf Sollpositionen und den Ursprungszustand (mit intakten Toppzeichen etc.) zu beschränken, wäre vorerst sinnvoll. Es ist also auch ein Problem der Aktualität der Karte. Auch das ein Grund, allenfalls eine Zusatzinformation mit Datum der Sichtung an die Tonne. Ja, genau. [...] Nationale Ergänzungen sind zulässig, jedoch keine Abweichungen vom festgelegten Standard. Was glaubst Du, was alles gemacht wird, obwohl es nicht zulässig ist... In der Seefahrt ist mir so etwas bisher noch nicht aufgefallen, allerdings kenne ich bisher auch nur die Ostsee. Du hast Recht, die WSAs und die meisten ihrer Pendants in der Welt bemühen sich im Allgemeinen schon sehr, Abweichungen zu vermeiden. Mein Argument ist nur: Ausnahmen *kommen* vor, deshalb muss die mit OSM arbeitende Software mit ihnen rechnen, und zwar bei allen Attributen und Kombinationen. Könnte mir aber vorstellen, dass die vom üblichen Schema abweichenden Tonnen dann extra auf der Seekarte erklärt werden. Die in der nautischen Kartographie gebräuchlichen IHO-Standards S-4 (ehem. M-4) und S-57 ENC lassen da einiges mehr zu, als in einem einfachen GUI-Editor ohne Weiteres abbildbar ist. In der Praxis werden Abweichungen manchmal nicht erklärt (z. B. wenn sie landesüblich sind [1]), manchmal umgangen (z. B. Tonnensignaturen ersetzt durch Schrift betonnt [2]), manchmal durch Kartenschrift erklärt [3]. [1] besondere Bedeutung von Toppzeichen auf Warngebietstonnen in Deutschland [2] einige privat bezeichnete Fahrwasser [3] sehr selten, steht dann eher im Seehandbuch Wie gesagt eine eingetragene Tonne, deren Bedeutung sich nicht erschließt, weil sie nicht im offiziellen Schema vorkommt, ist wertlos für die Navigation. Naja, sie hat vielleicht keine verkehrliche Bedeutung, aber immer noch einen Wert als Navigationshilfe (also zu Orientierungszwecken). -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Toppzeichen gesperrte Wasserflaeche
Olaf Hannemann wrote: Hallo Arne, Ganz nebenbei: wo gibt's denn rote Andreaskreuze als Toppzeichen? Das ist dann aber doch sicher irregulär, oder? Es gibt sie auf jeden Fall im Marinesperrgebiet im oberen Breitling in Warnemünde. Habe Fotos davon gesehen ;-) Hm, interessant: Sperrgebietstonnen mit rotem Kreuz als Toppzeichen, dafür aber anscheinend kein rotes Kreuz auf dem gelben Tonnenkörper. Von der Gegend habe ich leider gerade keine brauchbaren Karten zur Hand und kann daher nichts weiter dazu sagen, als dass es, ehm, ungewöhnlich ist. :) Das wäre dann übrigens so ein Fall, wo als Toppzeichen eben nicht das eigentlich dem Tonnentyp zugehörige Toppzeichen eingesetzt wird. In OSeaM ist eine der gelben Tonnen da übrigens interessanterweise als Backbordtonne getaggt. Die lag an der Stelle tatsächlich früher auch mal (~ 10 Jahre her). Anhand des fehlenden Source-Taggings und des Musters der Änderungen in OSM ist nicht auszuschließen, dass hier von älteren Seekarten abgezeichnet wurde. Interessant,kannst du mir eventuell einmal die Knoten ID zukommen lassen, damit ich den Nutzer darauf ansprechen kann? Solche Dinge sollten möglichst schnell geklärt werden, damit es keinen weiteren Eintragungen dieser Art gibt. Wie gesagt: die Eintragung könnte ja nach Quelle durchaus so richtig und gutartig sein, aber einen source-tag zu ergänzen wäre auf jeden Fall eine gute Idee. Vielleicht sollte der Online-Editor direkt ein Eingabefeld dafür vorsehen... http://www.openstreetmap.org/browse/node/638928753 Wie wird hier eigentlich von OSeaM die Rechtslage bewertet? [...] Der allgemeine Konsens ist zur Zeit, dass aus Karten nicht abgezeichnet werden soll Welches ist denn eine sinnvolle Quelle für nautische Grenzen (Sperr-, Naturschutz-, Reede- und andere Gebiete, Basislinie etc.)? Diese Angaben sind ja an sich nicht geschützt. und Karten auch nicht zur Korrektur der Lage der Seezeichen benutzt werden sollen. Allgemein ist die Position der Tonne ja aufgrund der Länge der Ankerkette und der herrschenden Strömungs- und Windrichtung ständig unterschiedlich. [...] Was ja eben gerade das Argument für die von mir vermutete Einstufung der Sollposition als amtliches Datum nach § 5 ist. Eventuell wäre es sogar sinnvoll, Soll- und Ist-Positionen getrennt zu taggen, wenn die Ist-Position tatsächlich zur Verfügung steht. Wie steht es denn diesbezüglich mit den NfS? Das ist ja im Prinzip auch ein Werk im amtlichen Interesse zur allgemeinen Kenntnisnahme. :) Diese sind gemeinfrei und dürfen daher zum Korrigieren bzw eintragen von Seezeichen benutzt werden. Was, wo hast Du denn das her? -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendern von Seezeichen und Editor
Falk Zscheile wrote: Am 18. Februar 2010 21:51 schrieb Christian Wagner wagnerschrist...@gmail.com : [Toms-Plugin für JOSM] Ja kenne ich, und das Teil macht IMHO den gleichen Fehler der hier immer wieder zu Verwirrungen führt. Es versucht die Seezeichen in eine OSM- untypisches Raster zu pressen. Das erscheint mir auch so. Da werden z. B. Topzeichen feste Tonnenfarben zugeordnet (Einzelgefahrzeichen etc.). Irgendwo auf der Welt gibt's dann ein Einzelgefahrenzeichen mit gelber Tonnenfarbe oder eine Kardinaltonne hat eine Lichtsequenz welche ich im Editor eben nicht auswählen kann und dann geht der Zinnober wieder von vorne los. Warum nicht mappen was wirklich da ist? Nein, dass siehst Du falsch. Die Topzeichen und Tonnenfarbe stehen immer in einem festen Zusammenhang. In der Theorie schon, klar. Aber die Erfahrung zeigt nun mal, dass es immer wieder aus verschiedenen Gründen Ausnahmen von der Regel gibt. Beispiele wurden schon genannt. Weiteres Beispiel: durch normale Abnutzung erlangen die Toppzeichen auf Backbord- und Steuerbordtonnen in Dänemark gerne schon mal die Form eines Balls. Wenn man den Ist-Zustand taggen wollte, wäre daher eine Backbordtonne mit rotem Ball als Toppzeichen in Dänemark nichts ungewöhnliches. Und ja, die Dinger sehen durchs Fernglas quasi genau so aus wie eine Mitte-Fahrwasser-Tonne. :-/ Bei Kardinaltonnen zeigen die Spitzen des Topzeichens immer in Richtung der schwarzen Bauchbinde der gelben Tonne. Gleicher Zusammenhang gilt für die Kennung (Lichtsequenzen) und Farbgebung bei den Kardinaltonnen.[1] Im Online-Editor auf http://map.openseamap.org/ kann ich z. B. das Toppzeichen nicht abschalten (die Checkbox ist disabled). In Norwegen haben Kardinalzeichen aber niemals Toppzeichen. Ebenfalls kann ich nicht die Kennung UQ(3) einstellen. Die ist zwar unüblich, aber zulässig. (Ferner kann ich keine Wiederkehr einstellen, was vermutlich einfach bisher noch nicht implementiert ist.) [...] Nationale Ergänzungen sind zulässig, jedoch keine Abweichungen vom festgelegten Standard. Was glaubst Du, was alles gemacht wird, obwohl es nicht zulässig ist... Da können noch so schöne Systeme definiert sein, die reale Welt sorgt immer noch für Abweichungen, mit denen Editoren und Renderer in OSM _prinzipiell_ umgehen können müssen. Ähnlich wie bei Mapnik Co. muss der Renderer nicht zwangsläufig alles perfekt rendern, was ihm über die Füße läuft. Was er nicht kennt, bleibt halt weg oder wird sinnvoll ersetzt (ist im Prinzip auf map.openseamap.org schon so implementiert). Die Hauptarbeit muss m. E. der Online-Editor leisten, indem er beim Einlesen von Objekten, die unvollständig oder unüblich getaggt sind, die Situation irgendwie sinnvoll darstellt (und die Daten ohne Zerstörung zurückschreibt, logisch). Das könnte _beispielsweise_ dadurch geschehen, dass bei Erkennen eines solchen Problemfalls (Objekt passt nicht genau ins vordefinierte Raster) statt der Editor-GUI zuerst eine rohe tag-Liste im Stil von JOSM angezeigt wird. Dem Nutzer könnte die Wahl gegeben werden, entweder die tags direkt dort zu bearbeiten oder (evtl. unter Datenverlust) auf den üblich GUI-Editor umzusteigen, falls gewünscht. Diese Lösung könnte nahezu alle Fälle mit der schönen einfachen GUI abdecken, wäre aber trotzdem flexibel für Änderungen. Ist aber nur eine von sicherlich vielen möglichen Ideen, und nicht unbedingt die beste. Auch der Renderer könnte diese Modularität und Unabhängigkeit der einzelnen Tags voneinander berücksichtigen und eben das Licht und den Leuchtturm bzw. die Tonne unabhängig voneinander zeichnen. So hat man dann auch eine Möglichkeit mit den unvollständig erfassten Seezeichen, welche in OSM nun mal auch erfasst werden, umzugehen. Wenn ich tagsüber an einer Boje vorbeifahre, so kann ich nun mal nicht wissen wie die Lichtcharakteristik aussieht. Wenn ich Nachts vorbeikomme so erkenne ich die Lichter, kann aber eventuell nicht die Farbe oder Form der Tonne sehen. Richtig. Wenn Du an einer Kardinaltonne vorbei kommst, dann kannst du das sehr wohl -- siehe oben. Die Frage ist nur, ob die Tonne tatsächlich befeuert ist (was man bei Tage nicht erkennen kann), Doch, am Vorhandensein des Leuchtträgers (oder -- mit etwas Erfahrung -- an der Tonnenform). nicht aber welche Kennung sie hat. Nein, die Kennung kann auch innerhalb des IALA-Systems durchaus variieren, und zwar ... [...], damit man die Tonnen im Fahrwasser bei Nacht auch schön anhand ihrer Befeuerung unterscheiden und in der Seekarte wieder finden kann. ... aus genau diesem Grund. Als Beispiel fallen mir spontan gerade bloß die Nordergründe ein (westlich Scharhörn), aber das Prinzip gibt's überall. (Übrigens, auch am Tage kann man Leuchttonnen erkennen, und zwar am Vorhandensein eines Leuchtträgers. ;-) ) -- Arne Johannessen ___ Talk
Re: [Talk-de] Rendern von Seezeichen und Editor
Olaf Hannemann wrote: Hallo Christian, Ich denke ja auch nicht dass ein grafischer Editor nicht irgendwann von Vorteil ist, aber warum nicht eine Zwischenlösung mit Vorlagen, damit kann man wie auch sonst in OSM eine einigermaßen stabile Datenbasis aufbauen und gleichzeitig bleibt man flexibel wenn die reale Welt nun mal nicht den Normen entspricht. [...] Klingt sehr gut. Würde auch Leuten wie mir den Einstieg erleichtern, die das OSeaM-Wiki etwas unübersichtlich finden. Ich habe mich mit den Vorlagen für den JOSM noch nicht weiter beschäftigt, mir wurde aber gesagt, dass unsere Syntax zu komplex sei, um das Proplem mit Vorlagen zu lösen. Man bräuchte -- falls ich es richtig sehe -- wohl eine Vorlage für jedes Einzelattribut (seamark:buoy_lateral:category, seamark:buoy_lateral:colour etc. pp.). Hmm, klingt sehr interessant. Vielleicht habe ich nächste Woche Zeit, mir das mal näher anzuschauen. Daher hat der Werner angefangen das JOSM-Plugin zu entwickeln. Das auch recht hilfreich erscheint, aber bisher noch sehr unvollständig ist (in Version 7). -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Toppzeichen gesperrte Wasserflaeche
es ein genormtes Steuerbord bzw Backbord Symbol, das in dem Sinne keine Topzeichen beinhaltet. Diese werden auch als perch starboard bzw perch port in die Datenbank geschrieben. Topzeichen werden vom Editor bei dieser Auswahl disabled, da es in dem Sinne keine Topzeichen gibt. Hm ... in ENCs wird das Reisig auf Stangen als Toppzeichen kodiert. Aber egal, in S-57 ist ja sowieso einiges etwas anders. Wie würde eine Stange mit abgefallenem Besen getaggt? :) Improvisierte bzw. private Betonnung können wir zur Zeit noch nicht darstellen. Demnach gibt es aber grundsätzlich schon Pläne, über das IALA-System hinauszuwachsen? -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Normierung von Seezeichen (was: kein Betreff)
AssetBurned wrote: On 14.02.2010, at 13:14, Mirko Küster wrote: Generelle Grundsatzfrage. Warum zwei Projekte, die eigentlich das gleiche machen aber doch wieder irgendwie ein eigenes Schema verwenden? [...] [...] Auch wenn ich das mit dem Datenbank aufblähen nur bedingt als problem empfinde, sehe ich es doch eher als hürde für neulinge an. Als Neuling kann ich das bestätigen. [...] Sind diese Tonnen nicht international oder zumindestens national normiert? Ja, sicher. Aber erstens gibt es zahllose verschiedene Normen für Schifffahrtszeichen. Allein in Deutschland z. B. eine internationale (IALA-A [1]), zwei verschiede nationale (SeeSchStrO [2], BinSchStrO [3]) und schließlich einige lokale (z. B. BSO [4]). Zweitens wird allerorts von den Normen abgewichen, wenn es dem Zweck dienlich ist, gerade kein genormtes Zeichen zur Hand ist oder einfach die ausführende Person sich für Normen nicht interessiert. Vergleiche Straßenverkehr: Es gibt zwar eine internationale Norm, aber jedes Land definiert dann national doch eigene Regeln, die den internationalen widersprechen oder sie auch teils völlig ignorieren (USA). Und manchmal (vereinzelt) finden sich dann Zeichen, die so in keiner Norm stehen. dann sollte es doch ohne weiteres möglich sein auf diesen normen aufzubauen und ne einheitliche struktur zu schaffen. Klar, das ist im Prinzip durchaus möglich und wird offenbar auch von OSeaM und FT angestrebt. Unter anderem wegen der zuvor beschriebenen Komplexität der tatsächlichen Verhältnisse ist das aber nicht ganz so einfach, wie es klingt. wenn das in kooperation der beiden projekte nicht funzt dann solltet ihr euch ne schlichtergruppe anheuern die von beiden projekten keine ahnung hat und das dann für euch macht. Heh :) [1] http://de.wikipedia.org/wiki/International_Association_of_Lighthouse_Authorities [2] http://de.wikipedia.org/wiki/Seeschifffahrtsstra%C3%9Fen-Ordnung [3] http://de.wikipedia.org/wiki/Binnenschifffahrtsstra%C3%9Fen- Ordnung [4] http://de.wikipedia.org/wiki/Bodensee-Schifffahrtsordnung -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Toppzeichen gesperrte Wasserflaeche
Olaf Hannemann wrote: Hallo Frederik, hallo Arne, Arne Johannessen wrote: [1] Es geht um den letzten ganz unten auf folgender Seite abgebildeten Tonnentyp (Bild 34): http://www.elwis.de/Schifffahrtsrecht/BinSchStrO/Anlagen/Anlage-8/ Aha. Also *hat* diese Tonne ein rot-weisses Topzeichen, und der Editor einen Fehler. Ohne es wirklich zu wissen, denke ich einmal die Tonne hat ein Topzeichen. Zur Klarstellung: ich war nie vor Ort und sage nur, um diesen Tonnentyp wird hier diskutiert. Ich vermute aber auch, dass ein Toppzeichen vorhanden ist. Der Editor hat an dieser Stelle keinen grundsätzlichen Fehler. Er schreibt _alle_ Daten _unverändert_ in die Datenbank zurück. Habe ich inzwischen mehrfach getestet. Was ist jetzt hier passiert? Der Leo hat ein Seezeichen zum bearbeiten geöffnet. Der Editor hat die Daten des Seezeichens geladen und das Topzeichen als unbekannt dargestellt, da er rot weiß rote Topzeichen nicht kennt. Ich schlage als Alternative mal den Begriff benutzerdefiniert / user defined vor. Einem Editor unbekannte Werte werden zumindest am Mac normalerweise so bezeichnet. Hier halte ich das für besser, weil dadurch klarer zum Ausdruck kommt, dass tatsächlich ein Wert gesetzt ist. Hätte der Leo dieses so gelassen wie es ist, wäre nichts passiert. Die Schlüssel wären genauso wieder in die Datenbank geschrieben worden. Nun hat der Leo aber, da er das rot weiß rote Topzeichen nicht auswählen konnte, gesagt dann hat die Tonne halt kein Topzeichen, und _bewusst_ das Topzeichen abgewählt. [...] Die hier diskutierte Tonne ohne Toppzeichen _darzustellen_ ist sicherlich okay. Dazu das Toppzeichen aus der Datenbank zu _löschen_, kann aber nicht die Lösung sein. Was habe ich für mich daraus gelernt? Ich werde ab sofort den Editor bei bekannten Schlüssel, aber unbekannten Wert, gar nichts mehr anzeigen lassen, um Leute daran zu hindern unbekannte Einträge zu löschen. [...] Klingt, als löse diese Änderung das Problem aus Sicht von OSM. Allerdings sieht die Toms-GUI nur eine Checkbox für Toppzeichen ja oder nein vor. Unterschiedliche Toppzeichen für denselben Tonnentyp können daher nicht mit Toms verarbeitet werden. Oder übersehe ich etwas? Es existieren ja nun durchaus Seezeichen, die nicht IALA, BinSchStrO oder sonstigen Normen entsprechen. Die haben dann teilweise auch recht unterschiedliche Toppzeichen. Beispiele: - DW-Route Kadetrinne mit gelben Lateraltonnen - dänische Regattatonnen mit Flagge - Reisig auf Pricken im Wattenmeer - improvisierte Betonnung Marke Benzinkanister mit Gewicht dran - privat bezeichnete Gewässer Wie werden derartige Seezeichen von Toms behandelt? Momentan kommt da im Zweifel ein Parse-Error: Seezeichen unbekannt, und eine Änderung der Daten mit Toms ist nicht möglich. Ist das schon der Sollzustand, oder planst Du grundsätzlich, Toms in diese Richtung zu erweitern? -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Toppzeichen gesperrte Wasserflaeche (was: kein Betreff)
Rolf Meyerhof wrote: Öffne ich das Tonnen Menue sehe ich eine gelbe Tonne mit einem gelben Kreuz und das ist falsch. Ein anderes Topzeichen kann nicht ausgewählt werden. Darum bleibt die Tonne ohne Topzeichen. Ist das dann nicht auch falsch? ;-) Was dann der Editor ändert oder nicht ändert ist so Du selbst schreibt ein Problem der Software. Frederik bezog sich auf Darstellungs-Software, welche die Datenbank nur ausliest. Der Editor ist aber eine Software, welche die Datenbank verändert und dabei -- wenn ich es richtig verstanden habe -- aufgrund eines Bugs zwangsweise die in der Datenbank existierenden Daten mit falschen Werten überschreibt. Vielleicht wäre es eine gute Idee, bis zur Korrektur des Fehlers im Editor diesen nicht mehr für gelbe Tonnen [1] einzusetzen. Ist der Editor Open Source, liegt der im OSM-Subversion? Wenn mir jemand den Code zeigen mag, werfe ich gern mal einen Blick darauf. Grüße, Arne [1] Es geht um den letzten ganz unten auf folgender Seite abgebildeten Tonnentyp (Bild 34): http://www.elwis.de/Schifffahrtsrecht/BinSchStrO/Anlagen/Anlage-8/ -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
