[OSM-talk-nl] Kleine jongens worden groot

Sat Sep 22 09:52:36 UTC 2007

Hallo Henk!

(Als ik het me goed herinner heb ik je op de HOSC gesproken)

Positiviteit is een absolute must! Ook ik herken de groeistuipen en 
ervaar dit als iets moois, de overgang van hobby project naar bruikbaar 
product is tomeloos interessant en fascineert me. Ik zal tussen jou 
opmerkingen proberen wat zinnigs te zeggen:

Henk van Cann (2value) schreef:
> Hoi,
>
> Ik lees de discussielijst al weken diagonaal door. Zal me met enkele 
> steekwoorden voorstellen: Henk van Cann - IT-er ('90)- ondernemer 
> ('94) - GIS ('92) - Wegener Falkplan ('99) - Open Source ('04)- 
> Holland Open ('07) - Joomla!dagen ('06) - mijn eerste Garmin 
> experience tbv Openstreetmap (15 juli 07 13:03u). 
>
> Recentelijk bespeur ik wat prikkelige vragen over de kwaliteit en 
> bruikbaarheid van data onder andere van AND.
>
> Je hebt vele soorten fouten, inconsistenties (intern en met externe 
> gegevens) en onduidelijkheden in een geodatabase zo groot als 
> Openstreetmap nu geworden is. En daar heb ik in verleden redelijk veel 
> mee te maken gehad.
> Kleine jongens worden groot en dat gaat met groeipijnen. Daarom even 
> een positieve beschouwing van mijn kant die grommers en morrelaars kan 
> helpen de kin omhoog te zetten:
>
> 1) Kwaliteit van geodata is altijd relatief begrip ten opzichte van 
> het doel dat je ermee hebt.
Absoluut! Je moet inderaad afwegen of de inspanning om de laatste 10% 
sluitend te krijgen opweegt tegen de meerwaarde. Zelf geloof ik meer in 
de "on demand" aanpak. Het mooie van OpenStreetMap is juist dat wanneer 
je fouten tegenkomt je deze direct kunt aanpassen. En hoe meer zielen 
zich bemoeien met fouten, hoe groter de kans is dat de fout praktisch en 
bruikbaar wordt aangepakt. Nog steeds vind ik dat het aantal deelnemers 
essentieel is voor het succes van OpenStreetMap. Daarnaast zal de vierde 
dimensie (tijd) ons helpen om de zaken steeds beter te maken.
>
> 2) Een weg kun je op 100 manieren modelleren, een spoorwegcircuit ook. 
> Het is belangrijk dat we in de Openstreetmap bijhouden wat de bron van 
> elk lijnstukje in de database is. Daar is al een veld met codes voor?
Er lopen op dit moment een aantal zaken; zoals je misschien weet hebben 
we in OSM te maken met ways->segments->nodes. Als je goed kijkt naar het 
model zou je feitelijk kunnen zeggen dat de elementen van het type 
segment geen meerwaarde bieden (Als iemand dit anders ziet hoor ik het 
graag) je kunt namelijk een way ook samenstellen uit nodes. Er zijn dus 
ook 3 elementen waarop de bron kan worden bijgehouden. Maar alleen de 
bron is eigenlijk niet goed genoeg. Je zou namelijk ook kunnen proberen 
de volledige mutatie historie bij te houden (dit is gangbaar bij 
wiki's). Op die manier zou je kunnen zien wat en wie er allemaal met 
elementen aan de gang is en op basis hiervan bepalen wat de waarde is 
van een element. Een van de mooiste wiskundige kunstvormen van geodesie 
is de waarnemingsrekening. Dit houdt in dat je op basis van een veelheid 
aan waarnemingen de waarde van een element "schat". Daarom heeft het 
mijn voorkeur niet alleen de bron op te slaan, maar ook de historie 
(eigenlijk de waarnemingen)
>
> 3) Een digitaal gemodelleerde ruimte (wegen, kustlijn, rivieren, 
> sporen, etc etc) kun je op duizenden manieren thematisch weergeven. 
> Zijn er al ideeen over gemeenschappelijke legendas die een mooi beeld 
> geven van hetgeen Openstreetmap nu heeft?
Dit vind ik op dit moment eigenlijk het minst relevant. De grote kracht 
van OSM zit hem in de database. Ik begrijp dat de kaart die wordt 
getoond op www.openstreetmap.org erg verduidelijkt wat er gaande is, 
maar in essentie bezit de database de kracht om afhankelijk van de 
toepassing de juist thematische weergaves te maken. Hier geldt; niets is 
onmogelijk. Het is eerder een kwestie van zoeken welke toepassingen op 
dit moment het meest levensvatbaar zijn en hier dan specifieke kaarten 
voor genereren. Zo kan ik me voorstellen dat er b.v. een wereldwijde 
fietskaart wordt gerenderd. Hierin zijn dan de snelwegen onopvallend, 
parkeerplaatsen onopvallend en de belangrijkste fietsroutes juist 
dik-gekleurd. Feitelijk zou dit inhouden dat je naast de huidige 
renderer een specifieke renderer voor fietsers ontwikkelt. Mooi toch!?
>
> 4) Fouten haal je eruit, inconsistenties blijf je houden. Simpele 
> oplossing: voor elk doel maak je je eigen setje kaarten (plus legenda 
> igv 2D presentatie) waarmee je kunt leven.
Precies, hier sluit ik me helemaal bij aan. Nogmaals, de kaarten zijn 
afgeleide producten, de basis, de database is de diamant van het project.
>
> 5) Ik heb in 1994 de bebouwde kom grenzen in de provincie Utrecht 
> mogen filteren uit een fantastisch mooie geodatabase met allemaal 
> foutloze en intern superconsistentie kaartlagen mogen halen. 
> Onmogelijke opgave. De bebouwde kom is geen absoluut begrip. Dus ook 
> de ligging van een lijn in Openstreetmap is soms afhankelijk van het 
> doel dat men met de opname heeft gehad. Ook hier geldt: als je maar 
> blijft weten wat de bron was en met welk doel het lijnstukje is 
> verzameld. Dat had een impopulaire naam "metadata" bij ons destijds; 
> en de bijhouding is weinig sexy en levert weinig waardering voor het 
> monnikenwerk dat het is. Dus wie eerst :-).
Kartografie is een vak, ik ben er vier jaar voor naar de HTS geweest en 
kan nog steeds geen sluitende antwoorden geven op vragen als begrens de 
bebouwde kom. Wel weet ik dat je destijds misschien beter met 
sattelietbeelden had kunnen werken dan met vector data ;-)
>
> Zijn er mensen die vanuit hun ervaring elders weten hoe we dit in 1 
> keer goed kunnen opzetten voor Openstreetmap en dan de kennis kunnen 
> inbrengen van talloze organisaties die zijn voor gegaan?
- Rollen en verantwoordelijkheden bepalen binnen de OSM organisatie 
(ESSENTIEEL!!!)
- Definieren wat OpenStreetMap is, duidelijk het onderscheid tussen de 
basis en afgeleide producten definieren.
- Het datamodel zo abstract en volledig mogelijk houden inclusief 
wiki-functionaliteit (mutatie registratie, historie bijhouden etc.)
- Toepassingsgebieden voor OpenStreetMap data definieren
- Per toepassingsgebied de afgeleide producten bepalen (kaarten die 
worden gerenderd óf datasets óf ...)
- Wanneer blijkt dat het toepassingsgebied aanpassingen behoeft in de 
OSM basis; een model-aanpassingstraject opstarten.
>
> Groeten,
>
>
> Henk
>
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Talk-nl mailing list
> Talk-nl at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
>   

-- 

Milo van der Linden
skype: milovanderlinden <skype:milovanderlinden?add>
mlinden at zeelandnet.nl <mailto:mlinden at zeelandnet.nl>
milovanderlinden at gmail.com <mailto:milovanderlinden at gmail.com>
milo at 3dsite.nl <mailto:milo at 3dsite.nl>
http://www.3dsite.nl

De informatie in dit bericht reflecteert mijn persoonlijke mening en 
niet die van een bedrijf of instantie. Aan de informatie kunnen geen 
rechten worden ontleend. Indien dit bericht onderdeel is van een forum, 
mailing-list of community dan gelden automatisch de bij het betreffende 
medium behorende voorwaarden. The information in this message reflects 
my personal opinion and not that of a company or public body. All rights 
reserved.If this message is contained in a mailing-list or community, 
the rights on the medium are automatically adapted.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-nl/attachments/20070922/4d1ee724/attachment.htm>