Het model is inderdaad door mij gemaakt. Vanuit mijn opleiding moeten we in osm een gebouw indoor modelleren om het vervolgens via osmosis over te zetten in een Postgresql database, deze vervolgens met Eclipse in een cityGML in 3D te laten bouwen. Echter is opdracht omschrijving zo vaag als kan en worden we in het diepe gegooid onder het motto van “trial en error”. Zoals te zien valt is dit allemaal getekend zonder enige handleiding of kennis van zaken. Ik kom inmiddels achter steeds meer dingen en oplossingen.
We moeten voor het intekenen gebruik maken van de blueprints of een evacuatie plan van een gebouw. In mijn geval is het huis van mijn ouders dat nog in aanbouw is. Het is ook niet de bedoeling dat dit huis qua inhoud online blijft in OSM zodra ik klaar met met deze opdracht.
Echter zit ik op dit moment nog vol met vragen over onduidelijkheden in het mapping-proces. Ik weet niet of deze thread daarvoor de juiste plaats is om deze te plaatsen.
Moet ik deuren als nodes in beide elementen tekenen? Bijvoorbeeld 1node in de hal en 1 in de aangrenzende kamer? (zelfde geld voor ramen).
Hoe gebruik ik de key’s voor ramen juist? Als een kozijn op 1 meter begint, en het raam is 1 meter bij 1 meter. Is mijn building:part:window:height=1 of 2? Sommige bronnen schrijven dat de height vanaf de grond gemeten is, andere zeggen dat het gemeten wordt vanaf de onderrand van je kozijn en dus vanaf je ‘breast’ hoogte.
Dus: building:part:window:height=1
building:part:window:width=1
building:part:window:breast=1
of building:part:window:height=2
building:part:window:width=1
building:part:window:breast=1
Moet ik binnenmuren ‘tekenen’, of kan ik alle elementen (rooms) aan elkaar vast leggen?
Is het belangrijk dat ik mijn key’s bij bijvoorbeeld een raam, elke keer geheel opnieuw uitschrijf?
dus: building:part:window=glass
building:part:window:height=1
building:part:window:widht=1
building:part:window:breast=1
of window=glass
height=1
width=1
breast=1
Bij het uploaden kan ik alle errors en warnings ‘wegwerken’ behalve de: “Relation type is unknown (*)”, deze warning slaat op alle relations die ik aanmaak.
Zijn hier mensen die ervaring hebben met het gebruiken van Osmosis, Postgres, pgAdmin III, Eclipse en CityGML?
Dan moet ik je helaas teleurstellen. De data blijft beschikbaar in de OSM database. Weliswaar redelijk verstopt zodra het huis verwijderd is, maar de historie blijft bewaard.
De 3D mogelijkheden in OSM zijn nog erg beperkt. Het meeste is experimenteel en veel is nog niet vastgelegd. Antwoorden op jouw inhoudelijke 3D vragen kan ik daarom ook niet geven. Vooral omdat ik er zelf te weinig van weet, maar het zou goed kunnen dat die antwoorden er (nog) niet zijn, omdat er nog niets over is vastgelegd.
Weet je zeker dat je het jezelf niet te moeilijk maakt? Misschien verwacht je docent niet meer dan een paar muren, een hoogte, de kleur en de vorm van het dak. Dat past prima in de huidige 3D standaarden binnen OSM en het zwaartepunt van de opdracht ligt dan op de conversies osm->postgresql (via osmosis) en postgresql->cityGml (mbv Eclipse en bijv. Java). Dat lijkt me persoonlijk pittig genoeg als het nieuwe materie is.
Ik vrees dat ik het mezelf eerder te makkelijk maakt. Er wordt veel van ons verwacht, het is eigenlijk de bedoeling dat je een gebouw modeleert in osm van 4/5 verdiepingen en meerdere kamers. En dan nog het liefst met liften en trappen, ongelijke vloeren en hellingen. In Duitsland (en dan vooral Heidelberg) zijn ze al erg ver met indoor (3D) modelling in OSM, en het is de bedoeling dat wij een soort spoed cursusje volgen om te ervaren wat er allemaal mogelijk is binnen OSM.
We worden dus ook niet opgeleid om mappers te worden voor OSM, maar leren het programma kennen zodat we het in de toekomst in het werkveld kunnen gebruiken/toepassen.
Ik zou de docent eens hier uitnodigen, als de opdracht is om osm als onderwijs testlocatie te gebruiken en daarna het gebouw te deleten. Is dit een verkeerde zaak. Hoe denkt de docent om te gaan met de BAG informatie. Neem aan dat de docent hier over heeft nagedacht.
Ik vraag mij wel af welk werkveld het is dat je docent voor ogen heeft?
Ik heb bijna twee decaden GIS ervaring, en hoewel OpenSource een duidelijke rol speelt in bijvoorbeeld webmapping en wellicht groeiend in andere regionen, zijn er voor echt professioneel 2D/3D civil engineering en werktuigbouwkundig of architecturaal ontwerp veel betere toepassingen beschikbaar. Denk aan AutoCAD, Microstation, City Engine, 3DsMax, SketchUp, ArcGIS, QGIS en nog zo wat van die pakketten met eindeloze mogelijkheden voor echt serieus ontwerpwerk, constructietechnische (sterkte-)berekeningen of geografische analyses.
Met een regeltje:
“Ervaring met indoor / 3D modelleren in JOSM”
in je CV kom je echt niet zomaar aan de bak in de 3D CAD Civil Design of overheids GIS wereld.
Hoewel JOSM een prachtige tool is voor datgene waarvoor het in eerste instantie is ontworpen, namelijk 2D lijngericht en tagging-gebaseerd tekenen en attribueren van OpenStreetMap node en way features, is het een extreem beperkte tool voor serieus architecturaal en werktuigbouwkundig ontwerp. Het is een beetje alsof je met een pikhouweel een computerchip gaat zitten ontwerpen…
Hier wordt weer eens zichtbaar dat we in OSM alleen een produktie-omgeving hebben, en geen test- of ontwikkel-omgeving. Het zou mooi zijn als er een soort speeltuin-versie van OSM komt, ook voor beginners.
Op zich vind ik dit soort innovatieve ontwikkelingen het ondersteunen waard. Maar helaas moeten we deze ontwikkelaars vragen rekening te houden met het feit dat ze direct in productie zitten te editten.
Je moet een apart dev-account hebben om er gebruik van te kunnen maken zo te zien.
Een echte proeftuin voor “gebruikers” die willen leren editten in OSM is dit echter niet, het is bedoeld voor ontwikkelaars die hun eigen OSM applicaties maken of willen testen.
Op dit moment doe ik een zeer brede master die allerlei aspecten van geografie met IT combineert. Ik leer werken met programma’s zoals ArcMap, CityGML, NetLogo, PCRaster, Eclipse, Geoda, PostgreSQL & pgAdmin III, en leer hoe ik ‘languages’ zoals SQL, UML en Python moet schrijven. Een onderdeel van deze master is een ‘onderzoek’ naar te voor- en nadelen van OSM. Voor welke doeleinden kan het gebruikt worden? Wat voor informatie kan er opgeslagen en verwerkt worden binnen OSM (geometry, topology, semantics, dimensions etc.)? Hoe kan het gecombineerd worden met andere geo-gerelateerde software? Zoals ArcGis, SketchUp, CityGML en andere simulatie of modelling tools?
Goetz en Zipf schreven niet voor niets in 2011 dat OSM aan het veranderen is naar een meer ‘indoor’ modelling tool, omdat daar veel mogelijkheden liggen. In Duitsland bijvoorbeeld zijn ze hier al actief mee bezig in OSM. In Nederland is dit nog een veel zeldzamer verschijnsel.
Ik vind het jammer om te moeten ervaren dat er hier op het forum vooral heel vijandig wordt gereageerd en niet bepaald behulpzaam. Het idee van een ‘open’ systeem is juist dat nieuwe mensen worden betrokken, worden geholpen en worden gevraagd naar hun beleving en perceptie. Wat ik hier vind is een handje vol mensen dat zichzelf ‘expert’ vind, vooral kritiek levert en bang is dat OSM verandert.
Goetz, M., & Zipf, A. (2011). Extending OpenStreetMap to Indoor Environments: Bringing Volunteered Geographic Information to the Next Level. In S. Zlatanova, H. Ledoux, E. Fendel & M. Rumor, Urban and Regional Data Management (1st ed., pp. 51-61). London, UK: Taylor & Francis Group.
Ik behoor gelukkig niet tot de experts maar lees sinds kort weer mee op dit forum. Wat mij opvalt is dat die “experts” er onderhand bijna een dagtaak aan hebben om alles wat door goed- en kwaadwillige amateurs verziekt wordt weer recht te breien. Daarom kan ik begrijpen dat men niet echt zit te wachten op hele schoolklassen die er maar wat op los experimenteren.
betrokken, je wordt uitgenodigd
worden geholpen, je wordt geholpen, zover dat mogelijk is. Je geeft dat zelf aan, weinig indoor mapping in Nederland. Zo ook geen experts.
beleving, die mogen ook wij geven, wij mogen kant tekeningen plaatsen, verrijk ons.
perceptie, die hebben wij ook, maar tegelijk ook veel respect.
een conclusie als niet behulpzaam, vooral heel vijandig.
Hier maak je een totale inschattingsfout.
Een opmerking/kritiek, moet je positief bekijken. Hiervoor moet je een open mind hebben.
Ik ben het met HanW aanwezig, ik ben ook zeker geen expert, maar de laatste tijd zijn er mensen die van alles niet volgens de ‘richtlijnen’ doen waardoor OpenStreetmap niet meer routeert. En dat is voor mensen die hem als kaart gebruiken niet handig. Jouw indoormodelling heeft niks kapotgemaakt. En ik vind ook niet dat het door jouw komt, maar door je docent die jullie zomaar OpenSourcemap op lijken te sturen.
Hoe ze dat in OSM in Duitsland doen weet ik niet. Maar wat iemand al zei: het zou misschien goed zijn als je docent(en) hier reageren.
En de experts zijn hier niet vijandig, misschien komt dat zo over maar dat komt doordat er een paar mensen echt niet wilden luisteren hier. En dat is in jouw geval absoluut niet zo naar mijn mening.
Ik krijg gewoon het gevoel alsof er veel weerstand is richting mensen die dit aan het ontdekken zijn. In mijn geval heb ik slecht mijn eigen huis van binnen gemodelleerd, en dat het dat niet netjes getekend is daar kan ik mee leven[1]. Ik heb niets verwijderd nog aangepast in de bestaande omgeving. En omdat het om mijn eigen huis gaat, ga ik wel de inhoud daarvan weer verwijderen/wijzigen zodra ik dit studie onderdeel heb afgerond.
Daarnaast stel ik hier een reeks inhoudelijke vragen over problemen waar ik tegen aan loop bij het modelleren, waar vervolgens iedereen overheen leest omdat men zijn mening wil geven over "het onderwijs op OSM’'[2][3][4][5]. Ik heb, voordat ik aan de slag ben gegaan in OSM, mij ingelezen op zowel de Wikipedia als enkele wetenschappelijke artikelen die beschrijven hoe je moet werken binnen OSM.
En ik ben het met jullie eens dat er vaak genoeg mensen tussen zitten die vreemde aanpassingen doen, dingen verwijderen en zo de database vernielen. Dat OSM geen test-omgeving is ben ik ook zeker met jullie eens.
Vanuit mijn studie proberen we OSM juist vanuit een academisch perspectief te bekijken. Op welke aspecten scoort OSM beter dan Bing en Google. Welke extensies binnen OSM zijn interessant voor het geo-gerelateerde werkveld. Mijn meerwaarde zit hem voor OSM dan misschien niet zozeer in het toevoegen van daadwerkelijke data[6], maar het schrijven van een kritisch artikel dat de mogelijkheden en tekortkomingen van OSM uiteenzet. Een artikel dat kritisch kijkt of OSM (al) geschikt is om indoor modelling tot bijvoorbeeld LoD4 te doen.
Het verschil tussen een proposalpage en wikipage,
Wanneer is books google geschreven, en welk tabel heeft hij overgenoemen.
Urban and Regional Data Management: UDMS Annual 2011
En proposal (inactiv) tabel overnemen kan het geen vaststaand feit zijn. Is het document is achterhaald?
Nu zijn niet alle wikipages goed bijgewerkt.
Dat moet je altijd in je achterhoofd houden.
Navraag leert, dat de BAG op deze locatie nooit geimporteerd is geweest.
Vanwege de al aanwezige indoor modelling.
Zou dus nog moeten gebeuren, omdat het gebouw ook niet goed op zijn plek ligt.
OK, dit maakt een hoop duidelijk over de achtergrond van je werkzaamheden binnen OSM. Dank daarvoor. Ziet er inderdaad uit als een bruikbare brede master, die veel aspecten en software in de GIS / CAD en programmeerrichting meepakt, en dus een hoop meer omvat dan geëxperimenteer met OSM.
Ik blijf bij mijn mening dat specifiek voor dit doel van indoor en 3D modellering al veel betere en professionelere, zij het niet altijd zonder kosten, tools beschikbaar zijn in de verschillende branches. Het is natuurlijk leuk dat veel rond OSM gratis en OpenSource is, maar daarmee heb je nog niet meteen “het beste gereedschap voor de klus”. Het werk bij de Duitse universiteiten heeft in mijn ogen toch meer een academische inslag (waar op zich niets mis mee is), dan direct grootschalige praktische waarde in de verschillende werkvelden waar geodata wordt gebruikt.
Zit een kern van waarheid in, aan de andere kant zijn er dezelfde problemen die een Wikipedia tarten, namelijk mensen die soms te makkelijk doen zonder eerst zich te verdiepen of in te lezen (waarmee ik niets wil zeggen over jou, want je geeft zelf al aan je aardig te hebben ingelezen). Dat zou helemaal geen probleem zijn als er sprake was van “private” data vergelijkbaar met je eigen pagina’s op een Facebook. Dat is echter niet het geval bij OSM, we gebruiken allemaal dezelfde data, foutjes of slordigheden kunnen daarmee vervelende consequenties hebben voor veel vormen van gebruik van de data, waar men zich vaak niet van bewust is. Het gebruik van de data is in OSM ook een stuk tastbaarder dan in Wikipedia. Slordigheden of onnauwkeurigheden in Wikipedia blijven goeddeels wat ze zijn: slordigheden en onnauwkeurigheden. In OSM kan een visueel niet direct zichtbare fout, echter wel grote consequenties voor het gebruik van de geodata hebben, denk de al gegeven routeringsproblemen. Maar ook kan een slordigheid tot grote visuele problemen leiden. We hebben Europa al een paar keer blank zien staan door slecht gebouwde kustlijn geometrieen, en slecht gebouwde multipolygonen kunnen in GIS systemen ook tot nodeloze gaten in de data leiden.
De consequenties zijn (soms ongemerkt) bij geodata gewoon veel groter dan een simpele spellingsfout in Wikipedia over het algemeen zou zijn.
Ik heb er zeker niet overheen gelezen, maar kan denk ik, zoals velen hier, nu ook niet direct heel goed hier antwoorden op geven. Dat heeft met twee dingen te maken:
Nog niet veel mensen in Nederland hebben denk ik met indoor modelling zelf geëxperimenteerd. Daarmee ben je toch een beetje op jezelf teruggeworpen, en is de respons ook minimaal.
De Wikipedia pagina’s zijn niet meer dan een globale richtlijn. Veel aspecten zijn gewoon nog niet uitgewerkt, en zullen dit misschien ook nooit zijn, want het blijft toch een enerzijds een “Open” datamodel, en anderzijds een groot vrijwilligersproject waarin tijd altijd een beperkende factor is.
Verder denk ik dat dit nu een van die aspecten is, die in veel van de professionele pakketten beter geregeld is: de datamodellen en modellering voor architecturaal of bouwkundig ontwerp is veel volwassener en consequent uitgewerkt / uitgedacht. Ik denk dat een deel van jouw vragen - op basis van de huidige webpagina’s, gewoon niet heel goed te beantwoorden is.
Om toch een poging te doen om een aantal van je vragen te beantwoorden:
"The individual areas share the same nodes where they share a wall in real world. The connection between a room an an corridor is done by an door= node, again shared by both objects."*
Dus geen dubbel ingetekende binnenmuren met volume volgens dit voorstel, slechts een enkele lijn / way. Ook de deur is slechts een enkele node tussen twee aan elkaar gelegde indoorelementen.
Ik denk dat de redenatie hier toch vooral is dat indoor OSM tagging toch vooral nog niet als volwaardige “bouwplannen” moeten worden gezien, maar dat het bij OSM indoor modellering eigenlijk voornamelijk gaat om de schematische “layout” van een gebouw vast te leggen ter oriëntatie, bijvoorbeeld voor het maken van een vloerplan van een winkelcentrum, zodat daarop vervolgens de POI kunnen worden aangegeven.
Voor oriëntatie is een enkele “muurlijn” meestal voldoende, en zou een exact bouwplan opbouwen (zoals jij wel enigzins heb lijken proberen te doen), gewoon nodeloos veel werk zijn. Ik denk dus dat de OSM indoor specificatie een pragmatische middenweg heeft proberen te kiezen hier, die het verdere gebruik ook vereenvoudigen.
Twee dingen:
Ik ben mij ook een beetje gaan inlezen op Indoor nu, maar nergens ben ik nog de door jouw gesuggereerde tagging
building:part:window:height=x
met superlange multiple “:” “prefix” tegengekomen. De building:part=x tag is volgens mij een tag die je niet direct nodig hebt bij Indoor tagging, of zelfs helemaal niet, het is de tag die bij Simple 3D buildings wordt gebruikt om de verschillende onderdelen van een gebouw apart te kunnen aangeven, en van aparte tags te voorzien.
Die lijkt mij persoonlijk ook het meest logisch / intuïtief, en minst foutengevoelig, je bestelt tenslotte toch ook een raam van 1 meter hoog en 50 cm breed bij de glasboer…
Zie ook mijn vorige opmerking aangaande building:part. Consequent zijn is sowieso nodig, ik lees op dit moment alleen window:height/width/breast=x in de Wiki (http://wiki.openstreetmap.org/wiki/User:Tordanik/Window_tagging), dus ook het tweede tagging voorstel van jouw hierboven lijkt mij niet handig. Beter je aan de Wiki te houden voor wat het waard is… dat is in ieder geval waar anderen ook naar kijken… (hopelijk)
Je geeft niet aan om welk relatietype dit eigenlijk gaat… wat stond er bij type=x? Houd er rekening mee dat op dit moment veel software sowieso niet of zeer beperkt met relaties om kunnen gaan. En het is al helemaal niet zo dat als je zelf spontaan een nieuwe relatie type definieert, dat dan de verschillende softwarepakketten ontwikkeld voor OSM hier automatisch mee om kunnen gaan. Het mappen van de vrije OSM relaties naar een relationeel database model is al helemaal problematisch, terwijl dat wel de basis is voor o.a. GIS systemen (en ook de OSM rendering database gevuld via osm2pgsql). Vrije key-value tagging en relationele databases zijn niet zo’n heel lekkere combinatie. Het is niet voor niets dat er ook een boom van NoSQL databases is.
Een paar, moet dan denken aan de NLExtract en diegenen die daar bij betrokken zijn (zie b.v. http://forum.openstreetmap.org/viewtopic.php?pid=567217#p567217)), maar hier zitten toch ook vooral mappers, die dus niet zozeer de “achterkant” kennen. Je stelt hier verder ook wel een erg open vraag. Wat wil je eigenlijk concreet weten?
En nee, ik heb deze specifieke ervaring ook niet. Mijn kennis ligt meer bij ArcGIS en (ArcSDE)Geodatabases.
