Es wäre schön, wenn Du genauer beschreiben könntest, wie Du Dir das vorstellst. So, wie ich es jetzt verstehe, wird es meiner Meinung nach nicht helfen. Mit welchen Schlüsseln willst Du arbeiten? Wenn Du im Extremfall nur einen Schlüssel nimmst, landest Du unweigerlich bei industrial_activity:ISIC4 (oder wie auch immer Du den nennen magst), und als Wert nimmst Du nicht den Zahlencode, sondern den Text, der zu dem Zahlencodes gehört. Das ändert im Prinzip nichts. Ich halte es sogar für schlimmer, als einen Code.
Nimmst Du mehrere Schlüssel, welche sollen es sein? Vorgeschlagen wurden z.B. (in anderen Diskussionen) industrial und wirtschaft_verwaltung (als zwei disjunkte Schlüssel). Da ist mir schon gar nicht mehr klar, was wozu gehören soll. Man landet dann bei amenity, tourism, craft, shop, office, healthcare, industrial, wirtschaft_verwaltung, …
Das ist alles, nur nicht systematisch. Und wenn dann der Nächste mit wieder anderen wirtschaftlichen Aktivitäten kommt, wird noch ein neuer Schlüssel eingeführt, wieder ohne Systematik. Das wird mit hoher Wahrscheinlichkeit im Chaos enden.
Wie ich oben schon geschrieben habe, ist die Komplexität nicht das Problem, die ist von außen vorgegeben. Die Systematik der Abbildung, um diese zu beherrschen, ist wichtig.
In einer anderen Diskussion wurde gesagt, daß so etwas wie industrial_activity:ISIC4 die bestehenden Schemata nicht ersetzen, sondern ergänzen soll. Ich denke, daß man vielleicht eher in diese Richtung denken sollte. Du tust das ja auch.
So ein Standard könnte helfen, alle existierenden wirtschaftlichen Aktivitäten zu beschreiben. Darin liegt sein Wert, einmal definiert kann man – sofern man will – alles beschreiben, ohne immer wieder die Frage nach noch immer fehlenden sprechenden Schlüssel-Wert-Paaren zu stellen. Das wäre der erste Schritt.
Als zweiten Schritt könnte man eine Zusammenführung zwischen den bestehenden Schlüssel-Wert-Paaren und dem Standard versuchen.
Das könnte z.B. auf zwei Sprachen hinauslaufen, eine sprechende, die solange sie beherrschbar ist, meiner Meinung nach immer nur einen Teil der Realität wird abbilden können, und einer nicht sprechenden, die aber vollständig, systematisch und eindeutig ist.
Falls das gut funktioniert, könnte sich jeder aussuchen, welche Sprache er verwendet. Der Gelegenheitsmapper spricht die sprechende Sprache, der andere den “Standard”.
So eine Sichtweise sollte die Akzeptanz für so etwas wie ISIC, NACE o.ä, sicher erhöhen. Was dann daraus wird, kann jeder in Ruhe abwarten.
Genau genommen wird man vermutlich die zwei Anforderungen
Den Gelegenheitsmapper einfangen
Ein vollständiges und eindeutiges Schema zur Verfügung stellen
nie gleichzeitig erfüllen können, wenn man nicht mit zwei Schemata / Sprachen arbeitet.
ich finde die Idee hochinteressant und würde Dich bitten, dass Du dafür ein Proposal vorbereitest.
Wie sich das durchsetzt und wie im Detail Tagging aussehen wird, ist erstmal nachrangig.
Was ich damit meinte ist, dass Proposals helfen, gute Taggingschemata zu entwickeln. Viele von uns haben bereits hingewiesen, dass damit diese Idee steht und fällt. Danach läuft das so, wie Du schreibst.
Nie ist eine lange Zeitperiode ;). Wir haben in OSM natürlich vieles, was kaum Chancen hat, jemals ausgewertet zu werden, weil es nur eine Randerscheinung ist und niemals Verbreitung finden. In der Hinsicht ist es natürlich richtig, vom Datenmüll zu sprechen.
Schlauchboot hat aber Recht, wenn er schreibt dass trotz der Fülle an Tagginschemata viele Sachen immer noch fehlen. Ich denke ein Vergleich mit externen Quellen ( deren Bezeichnung sollte eher nicht übernommen werden da wenig menschenfreudlich) kann hier hilfreich sein.
Meines Wissens haben die Industrie- und Handelskammern eine Statistik, in dem jeder Betrieb einer NACE-Einheit zugeordnet ist. Es macht aber wenig Sinn, an einem Betrieb vorbei zu laufen und sich dann auszudenken, in welche Klasse er gehört. Entweder man bekommt die offiziellen Zugehörigkeiten von den Industrie- und Handelskammern mitgeteilt und kann diese importieren, oder man lässt es bleiben. Sonst haben unsere Daten wenig mit der offiziellen Statistik zu tun und sind wertlos (wieder ein Fall von vorgetäuschter Genauigkeit). Ich glaube, die Industrie- und Handelskammern vertreiben diese Daten auch kommerziell.
Da zeigt sich eines der Probleme. Die IHK benutzt NACE-Einheit. Machen das alle IHKs in DE? Und was ist mit Städten, Kreisen, Regierungsbezirken, Bundesländern, dem Bund, anderen Ländern, der EU, den USA/NAFTA und letzlich der UNO? Benutzen die auch alle die NACE-Einheit? Oder hat da doch jeder seine eigenen Einteilungen?
So eine externe Klassifizierung, macht nur Sinn, wenn a) diese international genutzt wird und wenn b) die Klassifizierung als solche frei nutzbar ist. Schließlich sollte c) die Zuordnung von Betrieben/Betriebsstätten zu Klassen ebenfalls frei verfügbar sein.
Raten und freihändige Vergabe der Klassen eines Betriebs nutzen eigentlich niemanden. Inwieweit ein Betrieb auch mehreren Klassen angehören kann (schlecht abzubilden in den OSM-Daten), wäre dann noch zu prüfen.
Auch ergibt sich das Problem wie große Firmen die vom Bauteil über das Einzelgerät bis zu schlüsselfertigen System inklusive deren Planung und Finanzierung eine breite Palette anbieten, zu behandeln sind.
Nee, das ist alles nicht so einfach, wie es auf den ersten Blick erscheinen mag.
Vielleicht wäre es eine Lösung, sich an die NACE-Klassifikation anzulehnen, aber weiter bei beschreibenden Tags zu bleiben? So kann man die Tabelle der Branchen im Wiki auch weiterhin bearbeiten und offen halten. So könnte man auch eine Übersetzungshilfe für die verschiedenen nationalen Klassifikationen vorhalten, die Statistik-Mapper dann für eine Rückübersetzung verwenden können. Herausbekommen muss man, ob die NACE-Klassen an sich geschützt sind oder ob man diese in unser Wiki aufnehmen darf.
Ich glaube das ist genau das, was ich meinte: die ISIC (das ist die UN-Ausführung der NACE, die ich darum bevorzugen würde) könnte man eher als Anregung für neue Tags sehen und gleichzeitig versuchen, für statistische Auswertungen eine Übersetzungsseite ISIC-Code-zu-OSM-Tag aufzubauen. Das dürfte nicht allzu schwierig werden und niemand muss kryptische Tags setzen. Für einzelne, neue (beschreibende!) Tags kann man wohl größtenteils vorhandene Keys verwenden und diese um weitere values erweitern. Die Sache mit dem Copyright bleibt natürlich zu klären, in allen Dokumenten und auf der Website wird auf dieses hingewiesen und gefordert, eine Erlaubnis für die Verwendung einzuholen. Das sollte aber doch bei unseren Kontakten kein Problem sein!?
Ich hatte eingangs schon auf die EU-Verordnung 1893 (2006) hingewiesen. Man mag von der Regelungswut der EU halten, was man will, aber hier hat sie auch einen Nutzen. Diese schreibt NACE Rev. 2 für alle EU-Länder verbindlich vor. Genauers steht in Artikel 4, hier ein Ausschnitt davon:
Ich bin kein Jurist, aber ich lese das so, daß NACE Rev. 2 gewählt werden muß, daß jedes Land aber eine Verfeinerung wählen kann. Ich habe das an den eingangs ebenfalls zitierten nationalen Statistiken von Deutschland (WZ 2008), Österreich (ÖNACE 2008), der UK (UK SIC 2008) und der Schweiz (NOGA) überprüft. Wie ebenfalls schon geschrieben verwenden sie alle fünf- bzw. sechs-ziffrige Codes, wobei die ersten vier Ziffern mit NACE Rev 2 gemäß EU-Verordnung übereinstimmen.
Manchmal besteht die Verfeinerung nur durch Anhängen einer Null, wenn man keine Verfeinerung will. Die Schweiz gehört zwar nicht zur EU, aber viele non-EU-Länder übernehmen mittlerweile EU-Verordnungen in nationales Recht, obwohl kleine Verpflichtung dazu besteht. Norwegen ist in diesem Fall auch dabei. Die vollständige Liste kann man leicht recherchieren.
Ich finde, daß diese nationalen Verfeinerungen auch einen Vorteil bieten. OSM krankt bei manchen Schlüsseln daran, daß sie nationale Unterschiede nicht abbilden (können), was hin und wieder auch zu gewissen Problemen führt.
Dieses Problem hat man hier aufgrund der Hierarchie der Schlüssel ganz elegant gelöst. Wenn man WZ2008, NOGA oder was weiß ich verwendet, so weiß man, daß die ersten vier Ziffern in Deutschland, der Schweiz, … ganau dasselbe bedeuten, das alles danach nationale Spezialität sein kann (und wahrscheinlich auch ist). Man kann hier also nationale Besonderheiten ausdrücken, muß es aber nicht. Darum hatte ich auch vorgeschlagen, Angaben wahlweise in NACE, WZ2008, … zu erlauben. Es gibt immer eine Ebene, auf der man sich ganz genau versteht.
Hier ein Beispiel dazu, die eingangs erwähnten Banken:
Das sollte übrigends jeder verwenden können, der amenity=bank beherrscht. Hier übrigends die auch schon gelobte Dokumentation am Beispiel 64.19 – in 26 Sprachen frei Haus erhältlich! Ich nehme mal an, daß die Qualität der Übersetzung dort besser ist, als in den Map Features.
Die deutsche Verfeinerung gemäß WZ2008 hatte ich oben schon angegeben:
64.19.3 Kreditinstitute des Genossenschaftssektors
64.19.4 Realkreditinstitute
64.19.5 Kreditinstitute mit Sonderaufgaben
64.19.6 Bausparkassen
Und zum Vergleich die Schweiz nach NOGA
641901 Institute mit besonderem Geschäftskreis
641902 Kantonalbanken
641903 Grossbanken
641904 Regionalbanken und Sparkassen
641905 Raiffeisenbanken
641906 Handelsbanken
641907 Börsenbanken
641908 Ausländisch beherrschte Banken
641909 Filialen ausländischer Banken
641910 Privatbankiers
641911 Andere Banken
Auch dazu gibt es gesonderte Dokumentation. Und wenn man das alles nicht kann, oder will, bleibt man eben bei NACE 64.19. Jeder nach seinem Gusto. Bezüglich der Dokumentation noch ein Beispiel aus der NOGA zu 641901:
Pfandbriefzentrale der schweizerischen Kantonalbanken
Diese Dokumentation gibt es sicher nicht in 26 Sprachen, aber ausserhalb der Schweiz braucht die 01 in 641901 niemanden zu interessieren. Er/Sie sieht nur die 6419 und ignoriert in der Regel den Rest – und versteht was er/sie sieht.
Nordamerika (NAICS) ist hier etwas komplizierter. Deren Schema basiert auch auf ISIC, so wie NACE, hat aber andere Nummern. Auch das ist aber kein prinzipielles Problem, denn es gibt Umrechnungstabellen, z.B. hier. Dieses Beispiel bestätigt übrigends auch, wie schon erwähnt, daß ISIC und NACE fast identische Codes haben. (Ich habe bisher nur eine Ausnahme gefunden.) Auch NAICS hat Verfeinerungen, kennt aber auch die Abstraktion 522 – Credit Intermediation and Related Activities, und 5221 – Depository Credit Intermediation.
Ich möchte hier nicht mißverstanden werden. Man kann das Ganze sicherlich bis zum Exzess treiben, aber das sollte nicht sein. Ich wollte lediglich etwas Hintergrundinformation liefern um das Verständnis zu erhöhen. In Bezug auf OSM sollte man schon das rechte Augenmaß bewahren und schauen, was man daraus sinnvollerweise machen kann/will. Eine gute Lösung für OSM zu finden, ist die Absicht dieser Diskussion.
Die Codes haben einen hierarchischen Aufbau, dessen Wert man meiner Meinung nach nicht unterschätzen sollte. Ich hatte das in Beitrag Nr. 25 schon angedeutet. Hier noch ein Beispiel aus NACE Rev. 2
51 – Luftfahrt
51.1 – Personenbeförderung in der Luftfahrt
51.10 – Personenbeförderung in der Luftfahrt
51.2 – Güterbeförderung in der Luftfahrt und Raumtransport
51.21 – Güterbeförderung in der Luftfahrt
51.22 – Raumtransport
Das Beispiel ist vielleicht nicht besonders gut, aber es sollte reichen. Wenn jemand nicht ganz genau weiß, was er verwenden muß, kann er statt 51.22 zu verwenden, auf 51.2 zurückfallen, oder gar auf 51. Die nächst höhere Ebene wäre der Abschnitt H, zu dem 51 gehört: Verkehr und Lagerei. Ein Rückfallen auf den Abschnitt macht dann schon keinen Sinn mehr, die Aussage ist dann schon zu wage.
Hierarchien kann man in OSM mit normalen Schlüssel-Wert Paaren nicht so gut abbilden, daher ist das in OSM nicht so verbreitet. Ich finde aber, daß es lohnt, darüber nachzudenken.
Die Dokumentationen kann man wieder hier nachlesen. Da sieht man auch die Auswahlbox für die Sprache.
Auch das Vorhandensein einer Dokumentation ist ein Wert, den es zu berücksichtigen gilt. Wenn man NACE Rev. 2 komplett in Deutsch herunterläd, sind das immerhin 381 PDF-Seiten. Das mal 26 Sprachen muß einer erst mal aufschreiben. Crowd sourcing hin oder her.
Ich hab das mal angefangen, um zu sehen, ob das überhaupt auf die Füße fallen kann. Wenn mir jemand sagt, wie ich ein Bild (png) hier einbinde, kann ich das zur Verfügung stellen. So etwas für das vorhandene OSM-Schema zu machen, ist eine Heidenarbeit
Ich habe mir das auch mal angeschaut, es ist wie eingangs von dir beschrieben: vieles fehlt (über die Hälfte grob überschlagen, vor allem Industrie), vieles ist aber auch wesentlich stärker verzweigt als diese Codes (z.B. Geschäfte).
Zu der Hierarchie: Einerseits gibt es die in OSM schon, getrennt durch einen Doppelpunkt, das ist aber vergleichsweise kompliziert und bisher nur in Spezialfällen üblich. Von daher hat es vielleicht vor allem für die Logik der Tags sowie die statistische Auswertung einen Vorteil, wenn man eine solche Übersetzungstabelle hätte, anhand der man dann die jeweiligen Tags abklappern kann, ohne die Mapper mit Zahlenkolonnen zu überfallen.
Bevor wir eine solche Tabelle ins Wiki stellen, sollten wir uns allerdings einigen, welche. Ich wäre wie gesagt für die ISIC, da diese nicht nur für die EU gilt. Nachteil ist, dass es sie nur in wenigen Sprachen gibt, z.B. nicht in deutsch… Was auf jeden Fall geklärt sein sollte ist das Copyright.
Ich will noch gar nichts ins Wiki stellen, sondern nur ein Bild hier einbinden. Ich habe da (mehr oder weniger) ISIC, NACE, WZ2008, NOGA2008, ÖNACE2008 und NAICS2012 OSM für ein paar Beispiele gegenüber gestellt. Mehr als einen ersten Eindruck liefert das nicht. Es vertieft aber das Verständnis, wie diese Standards zusammenhängen. Das sollte man haben, bevor man sich auf einen einschränkt.
Ganz sicher. Ich meine, man sollte den Nutzern trotzdem die Wahl lassen, ob sie die Klarnamen der Branchen verwenden oder die Codes. Man kann nicht erwarten, dass sich jeder in diese (nicht ganz einfache) Materie einarbeitet. Wenn man gerade mal einen Laden eintragen will, reicht z.B. amenity=shop ohne weiter zu differenzieren. Für eine möglichst große OSM-Nutzerbasis ist eine einfache Bedienung unerlässlich. Eine aussagekräftige Tabelle im Wiki mit Übersetzung von NACE / ISIC / etc nach OSM-Klarnamen wäre ein Anfang. Vielleicht kann man ja auch Presets für JOSM und P2 erarbeiten, die diese Klassifikationen bereits (teilweise) abbilden?
Damit sollte die Verwendung von NACE meinem Verständnis nach eigentlich problemlos möglich sein.
ISIC scheint mir komplizierter, siehe hier, Auszug
Die Lizenz für einen normalen kommerziellen Anwender bezgl. ISIC liegt, ja nachdem, was man braucht, zwischen 50 und 100 Dollar, also für OSM erschwinglich, da findet sich bestimmt ein Spender. Die Frage ist, ob OSM hier als (ein) kommerzieller Anwender gilt…
Edit: …users are encouraged… Das ist für mich sowieso nicht verbindlich, oder sehe ich das falsch? (encouraged = ermutigt)!? Was bedeutet das also wirklich?
interessant, aber wie einige schrieben “eher abschreckend”.
Ich fände es müsste soetwas wie die Klassen geben ctaft, office, …
Wenn es dann ein globales Tag gibt in welchem man den lokalen Geschäftstyp hinterlegt, dann in Intervallen eine Analyse erfolgen und für die gängigen neue Hauptthemen definiert werden.
Danke! Bei manchen Foren braucht man so einen Umweg nicht, daher dachte ich…
Ich bin mir nicht sicher, wie man das am besten darstellen sollte. Nach einer flachen Struktur habe ich noch etwas anderes probiert. Hier ein Auszug (ich hoffe, das Anklicken liefert ein großes Bild…):
Verwendet habe ich die NACE Rev. 2 Codes, in der ganz rechten Spalte stehen die korrespondierenden ISIC Rev. 4 Codes.
ISIC entspricht NACE bis auf eine Ausnahme, wo NACE etwas feiner ist, als ISIC (gelb markiert).
Beim Imker sieht man, das NACE, ISIC und die europäischen nationalen Codes hier sehr grob sind. Sie kennen nur einen Unterpunkt von 01.49 (Sonstige Tierhaltung) und das ist 01.49.0. Sonst ist da kein weiterer 01.49.X mehr.
In Bezug auf die Gastronomie wird es dann schon interessanter. OSM liegt hier bzgl. der Granularität zwischen NACE und den nationalen Codes. Zu amenity=restaurant sind einige nationale Codes feiner, wobei meine Darstellung ungenau ist: die Codes von WZ2008, UKSIC 2008 und NACE2012 entsprechen meiner Ansicht nach einander nicht unbedingt. Einige Sachen kann ich auch nicht genau zuordnen.
Ich denke, es ist noch zu früh für ein Proposal. Man sollte wirklich mit so einer Tabelle im Wiki anfangen, wie von Dir vorgeschlagen – als Analyse. Dann kann man vielleicht bessere Schlüsse für ein Proposal ziehen. Ich denke aber auch, daß NACE und ISIC alleine dafür zu grob sind. Das kann man anhand der Gastronomie beobachten, und das wird bei Abschnitt G, Abteilung 47 (Einzelhandel) ähnlich sein, wo vermutlich alle shop=* liegen werden. Auf jeden Fall würde ich ISIC und NACE beide berücksichtigen. Es wäre schön, wenn Du da mitmachen würdest!
Wie so eine Tabelle aussehen sollte, ist mir noch nicht klar. Auf jeden Fall könnte man Links zu den jeweiligen Definitionen in den einzelnen Schemata (OSM, NACE, ISIC, NAICS2012, …) einbauen. Vermutlich sollte man das ganze auch in englischer Sprache verfassen.
Ganz sicher! Ich hatte oben ja auch schon geschrieben, daß man den Gelegenheitsmapper und ein vollsrändiges und eindeutiges OSM-Schema vermutlich nicht unter einen Hut (eine Sprache) wird bekommen können.
Viele Diskussionen laufen immer schnell auf ein entweder-oder hinaus. Das sollte man besser vermeiden.
Edit: Nachtrag: Na ja, hier noch die NAICS 2007 Unterpunkte zu NACE/ISIC 01.49. Die Veränderungen in NAICS 2012 kenne ich nicht.
Welche dieser Tabellen ist denn die detaillierteste? Die würde ich nehmen und den OSM-Tags zuordnen (ggf. müssen wir, um die größtmögliche Abdeckung zu erreichen, mehrere Standards zusammenfassen, also immer den detailliertesten Abschnitt). Überall, wo dann noch Tags fehlen, müssten Proposals zu angelegt werden. Die dann 1:1 belegte Tabelle (auf der einen Seite der kryptische Code, auf der anderen der OSM-Tag) könnte dann als Übersetzungshilfe für Auswertungen dienen, so wie du das anfangs skizziert hast.
Vorteile:
Ich kann anhand der bestehenden Statistiken zu den einzelnen Wirtschaftsbereichen abrufen, wie vollständig OSM ist;
ich brauche keine kryptischen Codes eintragen;
ich habe zumindest für diesen Bereich (wirtschaftliche POI) nahezu eine Garantie der Vollständigkeit, was sich vor allem für kommerzielle Nutzer positiv darstellen wird.
Diese Tabelle sollten wir im Wiki erstellen, kannst du da eine Seite vorbereiten, so ähnlich wie in deinem Screenshot? Da können wir dann ja die Details diskutieren und schon einmal die Tags zusammentragen. Der größte Brocken ist dann sicherlich die Ableitung von Proposals, aber bis dahin ist es denke ich noch ein weiter weg
Jeder Vorschlag, in das Taggingschema mehr Systematik reinzubringen, ist zu begrüßen. Auch wenn das naturgemäß die Bedenkenträger auf den Plan ruft.
Einige Punkte:
die Verwendung existierender Schemata (sofern international akzeptiert) ist hilfreich, weil sie sich leicht in einen Editor einbauen läßt
sie sollte hierarchich sein (damit man bei unbekannten Details immer noch die übergeordnete Kategorie mappen kann).
neben kryptischen Zahlencodes (die deshalb dennoch sinnvoll sein können) sollte es auch weiterhin die Möglichkeit geben, die gleichen Hierarchien textuell einzugeben, um den Mapper mit Minimalausstattung nicht auszuschließen.
auch wenn es derzeit kaum ausgewertet wird, sollte das Schema die Möglichkeit vorsehen, auf jeder Hierarchieebene multiple Werte verwenden zu können. Irgendwann wird es jemand auswerten.
Meinst Du hier mit “Tabellen” Schemata? In NACE Ref 2 steht folgendes auf Seite 41
Das sollte bedeuten, daß NACE feiner als ISIC ist. Ein Beispiel dafür gab es ja in dem von mir eingefügten Bild schon. Die aus NACE abgeleiteten nationalen Schemata sind noch feiner als NACE, doch wird man die wahrscheinlich nicht in ein generelles A ist detaillierter als B bekommen. Um das aber wirklich sehen zu können, muß man erst mal eine Tabelle haben.
Der Weg ist das Ziel :). Ich versuche mal eine Tabelle.
Dabei würde ich gerne mit collapse (show_hide) arbeiten, ähnlich wie auf der Webseite von eurostat zu NACE. Im WIKI gibt es dazu Möglichkeiten (mit Templates), allerdings bin ich da kein Experte. Vielleicht kann mir jemand Links zu Beispielen geben – vorzugsweise mit Tabelle und/oder vorzugsweise im OSM-Wiki? Sonst muß ich mir das erst zusammensuchen.
Ok. Ein Prototyp für die Tabelle ist fertig und hier zu bewundern.
Bis auf den Text am unteren Ende ist das der ganze NACE-Baum. Die Seite wäre damit fertig und sollte eigentlich nicht mehr verändert werden. Kann man so etwas einstellen (oder nur einer kleinen Menge von Leuten das Ändern erlauben?) Der Wiki-Code für diese Seite ist mit einem kleinen Programm erzeugt worden, eine (systematische) Anpassung oder Übersetzung in eine der anderen 26 Sprachen sollte vielleicht auch auf diese Weise (neu) generiert werden. Dann ist man relativ sicher, daß das Ergebnis stimmt.
Diese Seite könnte man dann bei Bedarf an anderer Stelle einbinden.
Bei den beiden ersten Leveln stimmen NACE und ISIC überein. Auf den Leveln 3 und 4 ist der korrespondierende ISIC-Code in eckigen Klammern zusätzlich angegeben.
Unter jedem 4. NACE/ISIC-Level hängt eine eigene Seite für die weitere Analyse. Aktuell sind nur zwei solcher Seiten angelegt, ein Spielball unter 01.11 und ein ernster gemeintes Beispiel unter 56.10.
Welche Spalten diese Tabellen haben sollen, wäre noch festzulegen, vielleicht erst mal nur die beiden OSM Spalten. OSM-Schlüssel und OSM-Wert sind verlinkt.
In Bezug auf NACE und ISIC tue ich mich mit dem Verlinken schwer. ISIC gibt es wohl nur in englischer Sprache online, das würde also beim Übersetzen nicht mehr funktionieren. Bei NACE sehen die Links nicht Vertrauen erweckend aus:
Kann gut sein, daß es eine Systematik hinter den darin enthaltenen Zahlen 18493784 und 18493814 gibt, und daß ich diese bereits verstanden habe, so daß sich auch die Links über das Programm generieren ließen. Ich weiß aber nicht, wie stabil das Ganze ist. Von Hand will man das wohl eher nicht machen.
Crowd sourcing hin oder her. 
