Import von Daten

Neben dem fehlenden eigenen Account muss ein Import auch auf auf imports-ML diskutiert werden. Mehr dazu: http://wiki.openstreetmap.org/wiki/Import/Guidelines

Die Sache mit dem separaten Account hat schon seine Gründe. Ein Beispiel wären Einschränkungen, die aus der Lizenz des Imports basieren. Nimm beispielsweise das aktuelle Problem in Polen. Keiner der Mapper weiß mehr genau, welche Daten er importiert hat und welche nicht. Das Kuddelmuddel aufzulösen hat keiner so richtig Lust drauf.

Ebenso geht es darum transparent zu machen, dass diese Daten importiert wurden. Woher soll irgendjemand in der Zukunft, wenn du das Projekt schon verlassen hast wissen, in welchem Changeset du welche Daten auf Grundlage welcher Lizenz importiert hast?

Wie du weiter verfahren sollst, wird dir pnorman sicher geschrieben haben.

Mag ja ok sein - aber wie nun weiter ?

Raus wieder rein ?
Ausserdem glaube ich nicht unbedingt eine solche Diskussion auf englisch zu führen!

Jan

Separater Account und vernünftige Dokumentation schön und gut, aber

aighes wrote:

muss ein Import auch auf auf imports-ML diskutiert werden

ist nun wirklich alberne Bürokratie. Nur weil sich pnorman gerne auf dieser Liste herumtreibt, muß man nun wirklich nicht fordern, daß jeder Kleinkram dort diskutiert wird. Gerade wenn es wie im vorliegenden Fall um eine einzige Stadt geht, sollte eine lokale Diskussion völlig ausreichen. Wenn es vor Ort eine aktive, gut kommunizierende Community gibt, die sich in der Frage einig ist, und die rechtliche Lage der zu importierenden Daten gesichert ist, braucht man nicht auch noch pnorman's Segen.

Wobei ich mich ganz nebenbei frage, warum man ausgerechnet Schachtdeckel importieren will...

und damit haben endgültig alle Klischees erfüllt.

Cobra wrote:

und damit haben endgültig alle Klischees erfüllt.

Ja, tut mir leid, daß ich wieder weit vom Thema abgewichen bin, aber nachdem ich den Unfug zu imports@ gelesen habe, mußte das raus.

Oli-Wan wrote:

Ja, tut mir leid, daß ich wieder weit vom Thema abgewichen bin, aber nachdem ich den Unfug zu imports@ gelesen habe, mußte das raus.

Kann dir nur zustimmen. Importe sind größtenteils Unfug.

Diskutieren ist wahrscheinlich ein etwas zu großes Wort. Man soll dort den Import ankündigen.

Das hat recht wenig damit zutun, dass pnorman sich da besonders gerne rumtreibt. Es geht einfach darum, dass die Leute, die den Karren im Zweifelsfall wieder aus dem Dreck zerren müssen vorher Bescheid wissen, dass da jemand etwas macht und man nicht hinterher per Zufall drauf stößt, dass jemand vor einiger Zeit großen Mist verzapft hat. Das Ausbügeln von Fehlern geht nun mal am besten, wenn der Fehler gerade erst passiert ist.

Das mit dem Klischee bezog sich darauf, dass deutschen Mappern gerne nachgesagt wird, auch noch Gullideckel zu mappen.

malenki wrote:

Kann dir nur zustimmen. Importe sind größtenteils Unfug.

Habe ich zwar oben nicht geschrieben, sehe ich aber auch so.

Cobra wrote:

Das mit dem Klischee bezog sich darauf, dass deutschen Mappern gerne nachgesagt wird, auch noch Gullideckel zu mappen.

Ach so. Ich dachte es ginge um das Klischee, daß dieses Forum aus jeder sachorientierten Frage gleich eine Grundsatzdiskussion macht. Da helfe ich aber gerne mit 😉

Hi !

da liege ich ja nicht ganz verkehrt - ich lasse das und werde lediglich das source-Tag nochmal berichtigen.

@Oli-Wan: den Grund des Importes hatte ich im Link [1] ganz oben beschrieben:

Mit Hilfe dieser Punkte, die auch in den Luftbildern weitestgehend erkennbar sind, sollte ein Mittel gefunden werden, um die Qualität der Luftbilder zu beurteilen. Leider hat sich die Transformation der Daten etwas in die Länge gezogen, so dass diese erst jetzt - ein Jahr später - abgeschlossen wurde.

Gruß Jan :-)

Lübeck wrote:

@Oli-Wan: den Grund des Importes hatte ich im Link [1] ganz oben beschrieben:

Mit Hilfe dieser Punkte, die auch in den Luftbildern weitestgehend erkennbar sind, sollte ein Mittel gefunden werden, um die Qualität der Luftbilder zu beurteilen. Leider hat sich die Transformation der Daten etwas in die Länge gezogen, so dass diese erst jetzt - ein Jahr später - abgeschlossen wurde.

In der Mailingliste schriebst du:

Einen Schachteckel im Bereich [1] mit Aerowest verglichen - die
Abweichung betrag nur ca. 0.6 m - vergleicht man diese mit der
Genauigkeit von einem unserer GPS-Empfänger ist das ok.

Du schließt aus der Genauigkeit der Luftbilder auf die der Schachtdeckel auf die der Luftbilder?
Das nennt man einen Zirkelschluss.

Lübeck wrote:

ich habe kürzlich in Lübeck Schachtdeckel die aus einer Spende der Entsorgungsbetriebe stammen importiert - Einzelheiten siehe [1] und neben lokalen Diskussionen hatte ich das ganze auch schon einmal in einem Posting in der ML hinsichtlich Tags gepostet.

Dort hast du nach der Import-Mailingliste gefragt und genügend Links bekommen...

Lübeck wrote:

Nun hat sich norman bei mir gemeldet und angemerkt das ich das nicht entsprechend den Richtlinien gemacht habe.

...und wunderst dich, dass das dann nicht gefällt?

Was mir seltsam vorkommt:
Du kündigst einen Import auf talk-de durch die Blume an, führst ihn ohne irgendwelche Quellenangaben in den Changesets oder an den Daten durch (und schaffst es schließlich im dritten Anlauf), bekommst eine private Nachricht von einem "Datenwächter und beklagst dich dann im Forum darüber?
Eigenartige Vorgehensweise.

Lübeck wrote:

Soll ich jetzt die Daten alle wieder löschen und nochmal mit einem anderen Account hochladen. Das ist doch "Beamten-Blödsinn" !?!?!

Du hast doch schon Übung im Hochladen und Löschen der Daten. 😛

• renn*
  

Wer es noch nicht weiß, pnorman ist der Rächer der Enterbten und hat eine Software, die alle Uploads überwacht....kein Witz. Jede Überwachungssoftware geht gegen meine Einstellung. Und diese wurde nie irgendwo angekündigt. Wenn ich einen Import planen würde (wobei Import relativ ist, ich lade nur Sachen über JOSM hoch und schaue mir vorher an, was passiert), würde ich die Changeset Größe klein halten und die Größe jedes mal ändern.
Natürlich sollte man sich vorher vollkommen sicher sein, dass die Änderungen auch willkommen sind. Wenn nur einer rumschreit, hat man verloren....also wirklich lokal ausdiskutieren. Aber irgendwelche Import Mailing Listen zu konsultieren, ist nun wirklich daneben. Ich verstehe nicht, wo der Value Add ist.

Hmm... Die Koordinaten hätte man zum Beispiel von Postgis umrechnen lassen können; wenn man die Daten in die DB importiert hat (im einfachsten Fall mit dem Shapefile-Loader) ist die Transformation nur noch ein SQL-Befehl... Oder auch von irgendeinem (freien) GIS. Fürs nächste Mal ;-).
Die Koordinaten als Attribut finde ich nicht gut. Was soll das bringen? Ob die Punkte gewandert sind, kann man doch an der Historie sehen, oder? Da wäre es eher noch sinnvoll gewesen, die Koordinaten im Ursprungssystem als Attribut anzuhängen, da es je nach Koordinatensystemen und Projektionen meist verschiedene Verfahren zur Transformation gibt und auch nicht alle gegenseitigen Umrechnungen exakt sind (einige sind nur Näherungsverfahren).
Ansonstens scheint mir das nicht ideal gelaufen zu sein, aber ich würde es jetzt auch so belassen.

achja, Jan....schreib ihm einen langen Text zurück in dem Du ihm lang und breit erklärst, dass das lokal gewollt/abgesprochen/etc ist und verlinke noch irgendwas, das wie eine Genehmigung aussieht...hast Du hoffentlich. Hat bei mir auch geklappt. Kam nix mehr

SunCobalt, ich halte deine Antworten und "Ratschläge" für sehr schlechte Trollerei. Imports waren und sind ein Problem aus vielfältigen Gründen, da gibt es nix zu diskutieren. Und wenn die User eben so unvernünftig sind, muss man auch zu härteren Geschützen greifen.

Übrigens hast du, Jan, gute 4MB sinnfreie Tags hinzugefügt. Das ist nämlich die Größe der Strings deiner eigenen Koordinaten-Tags sowie des sinnfreien und falschen source-Tags. Wenn man das in XML verpackt, ist das durch den Overhead noch mehr.

hi !

@malenki:

Du kündigst einen Import auf talk-de durch die Blume an, führst ihn ohne irgendwelche Quellenangaben in den Changesets oder an den Daten durch (und schaffst es schließlich im dritten Anlauf), bekommst eine private Nachricht von einem "Datenwächter und beklagst dich dann im Forum darüber?
Eigenartige Vorgehensweise.

das mit der fehlenden Quellenangabe ist leider ein Fehler der mir unterlaufen ist - zugegeben. Das mit dem Drittenanlauf waren mir nicht erklärlich technische lokale Probleme. Beschweren wollte ich mich nicht direkt - vielmehr war mir die Frage wie ich weiter verfahren soll.

Du schließt aus der Genauigkeit der Luftbilder auf die der Schachtdeckel auf die der Luftbilder?
Das nennt man einen Zirkelschluss.

Nein umgekehrt. Ich bin der Meinung die Vermessung ist als gut zu betrachten und dann vergleiche ich damit die Luftbilder. So sollte die auch eine homogenität der Luftbilder beurteilbar sein.

@Cottaer

Hmm... Die Koordinaten hätte man zum Beispiel von Postgis umrechnen lassen können;

Wer sich mit den Transformationen etwas näher auseinander setzt weiß das es nicht immer einfach ist "alles über einen Kamm zu scheren". Nicht umsonst gibt es in jedem Bundesland eigene Transformationsansätze zum Beispiel bei der Umstellung von Gauß-Krüger nach ETRS89.

Die Koordinaten als Attribut finde ich nicht gut. Was soll das bringen? Ob die Punkte gewandert sind, kann man doch an der Historie sehen, oder?
Ansonstens scheint mir das nicht ideal gelaufen zu sein, aber ich würde es jetzt auch so belassen.

Historie kann man soetwas manuell sicherlich nachlesen - aber wie will ich eine Vielzahl von Punkten prüfen? Wenn ich es richtig mal verstanden habe kann man zwar irgendwie auch auf die Historiendatensätze zugreifen - aber dafür ist wohl wieder eine lokale DB erforderlich. (wenn dem nicht so ist belehre mich eines besseren). Damit will ich dafür aber nicht anfangen. So kann ich bei jedem Punkt einfach vergleichen, ob die Tags mit den Node-Werten übereinstimmen.

@SunCobalt: nicht so lang - aber schon erfolgt. Das mit dem gesonderten Account war ihm aber sehr wichtig.

Zum Schluss stelle ich daher noch eine Frage.
Es wurde zu recht bemängelt das ich den Link zum Wiki im Changeset versäumt habe - kann man den irgendwie "nachschieben" und kann mir noch einer sagen in welcher der Tabellen ich meinen Import in dem Import Catalogue [1] ich das eintragen sollte. Das erschließt sich mir nicht ganz.

Gute Nacht
Jan :-)

[1] http://wiki.openstreetmap.org/wiki/Import/Catalogue

SunCobalt wrote:

achja, Jan....schreib ihm einen langen Text zurück in dem Du ihm lang und breit erklärst, dass das lokal gewollt/abgesprochen/etc ist und verlinke noch irgendwas, das wie eine Genehmigung aussieht...hast Du hoffentlich. Hat bei mir auch geklappt. Kam nix mehr

Sag mal geht's noch?
Es hat schon seine Gründe, warum es für Imports Regeln gibt und man sich davor tunlichst abstimmen sollte, gerade wenn die Erfahrung fehlt. Warum das so ist kann man an der mißglückten Aktion hier bestens sehen.

Also an und für sich, finde ich seinen "Import" in Ordnung (Bitte nicht schlagen)
Gut, über das "Wie" kann man streiten, da möchte ich mich auch mangels entsprechender Kenntnis nicht wirklich zu äußern.
Nur eine Frage hätte ich da:
Im Wiki findet man bei der Suche nach "Passpunkt" u.a. folgendes:
http://wiki.openstreetmap.org/wiki/DE:G … _bestimmen

Sollte man sie den nicht auch so taggen?

WIKI wrote:

man_made=survey_point
survey=ground_control_point
source=*
survey (für normale GPS-Geräte)
egnos (für EGNOS-korrigierte Signale)
on_top (für erhöhte Empfänger/Antennen)
differential (für Differential-GPS)
official (für gekaufte Punkte)
lat=* (Breite dezimal in WGS-84)
lon=* (Länge dezimal in WGS-84)
alt:wgs84=* (Höhe dezimal in WGS-84)
note=* 'position will change'
description=* '1. Sieldeckel im Immenredder westlich der Kreuzung Grützmühlenweg/Immenstieg'
name=* GCP_Immenredder_001 (der Name beginnt mit GCP (für GroundControlPoint)
type=* manhole_cover (für z.B. Gullideckel)

Würde doch in diesem Fall passen wie "Ar..h auf Eimer"...

Cobra wrote:

SunCobalt, ich halte deine Antworten und "Ratschläge" für sehr schlechte Trollerei. Imports waren und sind ein Problem aus vielfältigen Gründen, da gibt es nix zu diskutieren.

Imports gab es immer schon und wird es auch immer geben. Nur weil der größte Importeur aller Zeiten jetzt zum Feldzug gegen Gullideckelimporteure aufgerufen hat, muss ich das nicht gut finden. Klar sind Importe teilweise schlecht. Schlecht gemacht weil sie Dinge beschädigen oder ungewollt und dann beschweren sich die lokalen Mapper. Aber ich sehe nicht, dass irgendjemand ausser den betroffenen lokalen Mappern zu entscheiden hat, was gewollt ist und was nicht. Keine DWG und keine Import ML. Wenn jemand Mist baut, soll er auch eins drüber kriegen. Aber das die DWG die Changesets aller Mapper überwacht und auch ohne Beschwerden tätig wird, finde ich nicht gut. Wenn Du das als Trollerei ansiehst, ist mir das ziemlich egal. Ich werde mich nicht dem DWG Zwang beugen....solange es keine praktikable und demoktratische Import-Richtlinie gibt und ich weiß, wie ich mich dem Zugriff der OSM Blockwarte entziehen kann.

Moin !

@jman1983: ich wußte doch, das ich nicht ganz falsch liege und wenn ich das am Morgen überfliege, dann ist meine Source auch mehr richtig als verkehrt - nur das survey als Basis fehlt. Habe den Weg der Koordinatenentstehun dokumentiert.

Was Transformationen abschließend betrifft sind diese von ETRS89->WGS84 einfacher zu händeln als die von GK->ETRS89 weil viele örtliche Besonderheiten im Rahmen der Umstellung behandelt werden und diese habe ich versucht zu berücksichtigen.

QSunCobalt: eine Antwort die sich einmal nach dem Ziel meiner Anfrage orientiert und nicht nur Schelte verteilt.

Aber ich sehe nicht, dass irgendjemand ausser den betroffenen lokalen Mappern zu entscheiden hat, was gewollt ist und was nicht.

Es wurde mit dem Import ja auch nichts beschädigt etc. Die Punkte sind mit nichts verbunden und haben nichts verändert in Lage und Attributtierung.

Gruß Jan :-)

Source ist NICHT dafür gedacht, unwichtige Details des Imports zu dokumentieren. Wie du die Koordinaten umrechnest, interessiert fast niemanden, der die Objekte findet. Wenn der Import gescheit dokumentiert ist, kann man das dort nachlesen.
Im Source-Tag sollte die Datenquelle stehen. Ein "Survey" dadrin ist mehr als falsch! Das heißt nämlich, dass du die selbst vor Ort erfasst hast.

Lübeck wrote:

Es wurde mit dem Import ja auch nichts beschädigt etc. Die Punkte sind mit nichts verbunden und haben nichts verändert in Lage und Attributtierung.

Das kann der Importeur dieser Daten auch guten Gewissens sagen:
http://www.openstreetmap.org/?lat=45.38 … 5&layers=M

...

was hackt ihr auf Jan rum? Wenn ihr nen Aufreger braucht, kümmert auch um sowas
http://www.openstreetmap.org/browse/way/13813364
Dagegen ist die Datenmenge von Jan ein Tropfen im Ozean. Cobra, wenn Dich die 4MB von Jan stören, ich habe hier noch eine 5MB Platte von meinem Amiga 500 rumliegen. Ich schicke sie Dir gerne.

Und malenki....lass Jan lernen, Du brauchtest einen wesentlich größeren Import, um zu Deiner jetzigen Meinung zu kommen. Und der war, wenn er noch da wäre, wesentlich kontroverser.

SunCobalt wrote:

... ich habe hier noch eine 5MB Platte von meinem Amiga 500 rumliegen. Ich schicke sie Dir gerne. ...

Sorry - total Off-Topic: Ich hätte Interesse.

Gruß Klaus

SunCobalt wrote:

Und malenki....lass Jan lernen, Du brauchtest einen wesentlich größeren Import, um zu Deiner jetzigen Meinung zu kommen. Und der war, wenn er noch da wäre, wesentlich kontroverser.

Hast ja recht. Man soll aus seinen Fehlern lernen, nicht aus denen anderer.

Moin !

ich habe heute morgen wieder Post von norman gekommen !

As I haven't heard back from you and you haven't proposed an alternate solution or contacted imports@ I'll go ahead and revert tomorrow. You can then go through the steps in the import guidelines before importing again.

Damit "droht" er den Import zu löschen !

Habe darauf hin folgendes gemailt - mal sehen ob er sich damit zufrieden gibt.

hi !

we discuss in german forum and the result is - for today ok; but for the next import i had to work other !!!!

http://forum.openstreetmap.org/viewtopic.php?id=18156

regards Jan :-)

Vielleicht kann einer von Euch auch noch eine Mail mit der Stärkung meiner Aussage mailen.

Gruß Jan :-)

Hallo Jan, woraus schließt du, dass dies das Resultat dieser Diskussion ist?

Das Resultat einer Diskussion ist nicht, dass sich der Fragesteller die Meinung eines Teilnehmers rauspickt und dann als Resultat verkauft.

Du warst grade Thema auf #osm

Das Resultat ist, dass keine auf die Fragestellung wie mit dem Import umgegangen werden sollte geantwortet hat. Somit hat auch keiner gesagt, dass das Löschen die richtige Lösung ist.

Und zu welchem ergebnis ist man auf #osm gekommen?

Ich bin dafür, zu reverten und das ganze sauber zu machen.

Also eigener Account, gescheite Dokumentation (die Wikiseite finde ich dafür in Ordnung, das kann so blieben) und Taggingschema (d.h. ohne Koordinaten in Tags, klarer source-Tag, der auf die QUELLE der Daten hinweist, bspw. source=EBL oder sonst etwas; nicht der Weg der Koordinatentransfomation, der interessiert kaum jemanden).
Im Changeset sollte auch ein Link zur Dokumentation sein, auf der Benutzerseite ebenfalls sowie ein Link zu deinem Konto als Verantwortlichem.

Du schreibst übrigens von über 55000 Deckeln, dein Changeset enthält aber "nur" 50001 (bei einer edit-Grenze von 50000... hä?). Da fehlen also wohl sowieso welche. Da du geschrieben hast, dass nicht ausgedünnt werden soll, passt das nicht zusammen. Ich sehe gerade, dass es versteckt in deiner Changeset-Liste (/edits) noch Changeset 12910347 gibt. Das steht aber wieder nicht auf der Wiki-Seite.
Wenn du dann endgültig importierst, solltest du das in kleineren Paketen machen, also bspw 10000 auf einmal. Solche Riesenchangesets sind nämlich schwer handhabbar und es wurde schon diskutiert, die 50k-Grenze deutlich zu verringern, um auf brauchbare Größen zu kommen. Ich versuche gerade, das Changeset zu laden, um zu schauen, ob sich das noch handhaben lässt, sind ja nur Nodes.

BFX wrote:

Und zu welchem ergebnis ist man auf #osm gekommen?

Paul Norman will den Fall an aighes übergeben 😉

Cobra, wenn ich helfen kann, sag bitte Bescheid. Es sind übrigends oft 50.001 Objekte, da habe ich mich auch schon gewundert

Hat er auch gemacht...

ich hab hier ein nettes Script von Maxbe. Mit dem könnte man prüfen, ob es schon ähnliche Objekte in der Gegend gibt und so Duplicate vermeiden

Hallo Jan :-),

Lübeck wrote:

ich habe heute morgen wieder Post von norman gekommen !

...

Damit "droht" er den Import zu löschen !

Mach doch was positives draus. Ich finde zwar den Zirkus, den unser Oberbürokrat in dieser Sache veranstaltet, übertrieben, und wenn ihr euch vor Ort darüber einig seid, könnt ihr meinetwegen auch Pflastersteinfugen und Schlaglöcher importieren. Aber wenn die Schachtdeckel nicht "um ihrer selbst willen" in OSM sollen (sprich, weil die Information so nützlich ist und allen OSM-Nutzern zur Verfügung stehen soll), sondern nur zur visuellen Beurteilung der Lagegenauigkeit von Luftbildern, also OSM-internen Zwecken dienen, park sie doch einfach in einem eigenen Overlay, die technischen Mittel hast Du ja. Ein lokaler Datenbestand mit den Schachtdeckeln, und daraus eine gerenderte Karte, die man per WMS/TMS in JOSM über das Luftbild blenden kann, erfüllt den Zweck. Alternativ/ergänzend könnte man eine nicht-hochladbare .osm-Datei bereitstellen, die sich jeder interessierte Nutzer selbst als Ebene in JOSM anzeigen läßt.

hi !

das mit Source kann ich noch ändern - das mit den Koordianten sehe ich nicht ganz ein zumal es auch in [1] enthalten ist.

Wir werden heute auf dem Lübecker Stammtisch nochmal darüber sprechen.

sondern nur zur visuellen Beurteilung der Lagegenauigkeit von Luftbildern, also OSM-internen Zwecken dienen, park sie doch einfach in einem eigenen Overlay,

das soll ja nicht nur für mich sein !

@SunCobalt: Du kannst Dein Skript ja nochmal laufen lassen - bin gespannt.

Gruß Jan :-)

[1] http://wiki.openstreetmap.org/wiki/DE:G … _bestimmen

Ich selbst hätte auch den Weg eines Overlays bzw. eines osm-Files gewählt - einfach aufgrund des großen Umfangs und ziemlich beschränkten Nutzens. Aber das ist Sache der lokalen Community.
Hier geht es nur aber um die Art und Weise des Imports.
Und denkt daran, der zusätzliche Aufwand ist nicht hoch. Dafür schlagen aber mit schöner Regelmäßigkeit Leute vor, man solle Peer-Review-Modelle, Beschränkungen von Changesets für Anfänger, etc pp einführen. Wenn was schief geht (siehe Lizenzwechsel, siehe kaputte Imports, ...), ist das Geschrei groß. Das hat schon alles seinen Sinn. Um wem das alles zu kompliziert ist, der sollte eben nichts importieren.

Die Koordinaten sind die Idee eines einzigen Users, nämlich "Markus B". Es ist und bleibt einfach redundante Information.
Das Changeset ist übrigens immer noch nicht herunterladbar. Offensichtlich ist es zu groß. Das zweite kleinere ist kein Problem.

Du kannst ihn gerne Nennen wie du willst... nur haben die Import-Regeln ihre Gründe und auch der Lizenzwechsel hat gezeigt, dass die Regeln eine sinnvolle Sache sind.

Ob solche "Tricks" sinnvoll sind muss Jan entscheiden. Dann kann es auch schon mal sein, dass das Amt bei der nächsten Anfrage nachfragt, was denn mit den anderen Daten geworden ist. Die sollten doch in OSM importiert werden. Wir können diese dort aber nicht finden. Es scheint also so zu sein, dass OSM unsere Daten gar nicht haben möchte...

Jan :-) -

Lübeck wrote:

sondern nur zur visuellen Beurteilung der Lagegenauigkeit von Luftbildern, also OSM-internen Zwecken dienen, park sie doch einfach in einem eigenen Overlay,

das soll ja nicht nur für mich sein !

lies das Posting doch bitte einfach mal aufmerksam bis zum Ende und achte dabei auf die Stichworte "gerenderte Karte", "WMS", "bereitstellen".

falls Du Dich entscheidest, die Daten in OSM haben zu wollen, frag doch auf der Import ML mal nach, ob Du sie wirklich reverten und neu einspielen sollst. Kannst ja das schicken.

Dear import list,

in order to ensure compliance with the import guideline as layed out in the OSM wiki, I would like to ask you wether it is necessary to revert the local manhole import and re-import it again under a special user-id or if there is any way to "heal" it retroactive. With the exception of the requirements to inform @import and to use a specific user-id, I assume the import is already in compliance with the import guideline. A wiki page for this import exist and it was discussed with the local community.

Kind regards

Falls Du Dich für ein WMS Layer entscheidest, wühle Dich mal durch den AeroWest Thread. Da steht, wie man ein WMS Server aufsetzt. Von da bis zum transparenten Rendern von JOSM Hintergründen ist es dann nicht mehr weit.

Wegen den Duplikaten schaue ich heute Abend mal

@oli: und wenn ich mL keinen Bock haben sollte wäre der end weg !

Jan

Lübeck wrote:

@oli: und wenn ich mL keinen Bock haben sollte wäre der end weg !

Okay, ich gebe auf. Wenn Du den direkten Import in OSM für sinnvoller hältst, rede ich Dir nicht mehr rein.
Allerdings sehe ich da das gleiche Problem. Wenn du "mL keinen Bock" mehr hast, entfällt auch die Pflege der importierten Schachtdeckeldaten. (Auch die Lage von Kanälen und Kanalschächten kann sich im Zuge von Bauarbeiten zwar selten, aber gelegentlich eben doch ändern.)

Wenn du "mL keinen Bock" mehr hast, entfällt auch die Pflege der importierten Schachtdeckeldaten. (Auch die Lage von Kanälen und Kanalschächten kann sich im Zuge von Bauarbeiten zwar selten, aber gelegentlich eben doch ändern.)

Die Frage war nicht ernst gemeint ?

Die Community - denn wer Pflegt die Daten von anderen "Aussteigern" ???

gruß Jan .-)

Lübeck wrote:

Die Frage war nicht ernst gemeint ?

Welche Frage?

Lübeck wrote:

Die Community - denn wer Pflegt die Daten von anderen "Aussteigern" ???

Wer pflegt die Daten von Importeuren? Erfahrungsgemäß niemand, am wenigsten die Importeure selbst.
Ein hübsches Beispiel sind die Funkantennen in NL, oder die zone-Tags von Haltestellen ebenfalls in NL, mit denen der Importeur auch gleich das deutsche Grenzgebiet beglückt hat.

Welche Frage?

... na die wer dieses pflegt !

Gruß Jan :-)