[OSM-talk-nl] vb.net mapping en routing, wie doet er mee?

Milo van der Linden mlinden at zeelandnet.nl
Wed May 16 18:45:16 BST 2007


>> Wat is de omgeving waar jij de voorkeur aan geeft dan Stefan?
>>
>> Ikzelf vind Java juist geen optie omdat de snelheid en
>> geheugen-efficiente lager is dan die van b.v. C++, Mijn JOSM vindt het
>> b.v. heel lastig om de planet.osm in te lezen.
>>     
>
> Ja, maar dit komt grotendeels door de grootte van de planet.osm. In
> C++ zal het waarschijnlijk wel efficiënter gaan, maar dan nog zal je
> waarschijnlijk een probleem hebben als je de hele planet.osm gaat
> inlezen, omdat het gewoon een paar gigabyte aan data is.
>   
Ik weet niet goed of er gebruik wordt gemaakt van de spatial functies in
mysql (http://dev.mysql.com/doc/refman/5.0/en/spatial-extensions.html),
misschien dat ik het database team daareens naar kan vragen. Idd. de
osm-xml file is hier gewoon niet heel handig, maar  een bepaald stuk
extracten op het moment dat je het nodig hebt is het ook goed
natuurlijk. Of extracties maken op hoofdwegen en alleen bij begin en
eindpunt van een route detail topo ophalen...
> Als ik het zelf zou schrijven, zou ik de delen die heel efficient
> moeten zijn in C schrijven en de rest in python. Maar als in de
> subversion repository van OpenStreetMap kijk, dan zie je daar perl,
> ruby, python, java, C++ en C. Het is niet zo dat er slechts 1 of 2
> programmeertalen gebruikt worden...
>   
Wat C betreft ben ik het met je eens, .net is namelijk enorm
/inefficient /met arrays.

Bij mijn vorige baas heb ik een GIS oplossing gemaakt met een team van 3
programmeurs waarbij het Nederlandse wegennet (TeleAtlas) werd opgeknipt
in de 25 brandweer-regio's. Per regio werden vervolgens routerings
vraagstukken uitgerekend.

Inhoud van de dataset:
- wegsegmenten van één regio
- alle adressen in x,y met de brandweerzorgbehoefte (aantal
blusvoertuigen ter plaatse, evt. ladderwagen etc.)
- kazernes(x,y)
- voertuigen (ladderwagens, blusvoertuigen etc. gepositioneerd op de
kazernes)
- woonlocaties vrijwilligers
- werklocaties vrijwilligers

Ons systeem rekende vervolgens het volgende uit:
- Vanaf het moment dat de pieper gaat -> vrijwilligers gaan naar kazerne
-> voertuig vult zich met bemanning -> voertuig start met rijden ->
routering -> aankomst op incident locatie.
- Dit voor alle voertuigen in de hele regio
- De resultaat tijden werden vervolgens aan de normtijden gekoppeld
zodat zichtbaar werd of de brandweerzorg binnen de gestelde normtijd
wordt uitgevoerd.
- Per brandweer regio werd een management presentatie (kaart, grafieken
en lijsten) gegenereerd.

Het geheel was geschreven in vb, vb.net en deels in C++, database SQL
Server, GIS data in MapInfo +/- 2 Gb per regio, binaire
routeringsbestanden +/- 100Mb per regio
Totale rekentijd voor bovengenoemde proces was voor de  regio's met de
hoogste wegendichtheid (Regio Rijnmond/Regio Amsterdam/Amstelland)
maximaal 3 minuten op een windows systeem 1,6Ghz Intel, 1024Mb ram.

Naast deze regio-oplossingen heb ik de berekening een keer (In opdracht
van Binnenlandse Zaken) landelijk uitgevoerd voor calamiteiten
(ontploffingen, snelweg-rampen en terroristische aanslagen)

Omdat de meeste navigatie software alleen van A naar B routeert
(enkelvoudige routering) evt. met wat via punten, moet het dus met de
toolset die we destijds gebruikten mogelijk zijn om met het Nederlandse
wegen bestand te rekenen onder de 10 sec. Europa breed: max 30 sec,
wereldwijd max. 2 minuten. Dit is in feite wat ik wil gaan proberen en
ik wil hier heel graag mensen voor vinden die dit samen met me willen
doen, dit is niet iets dat ik in mijn eentje kan.

>   
>> Ik zoek naar een generiek karakter, misschien kunnen we (mits er mensen
>> zijn die hier écht verstand van hebben) kijken of we gelijktijdig op het
>> microsoft.net framework en mono aan de slag kunnen. Voor conversie
>> bibliotheken is dit zeker geen probleem, alleen het bouwen van
>> user-interfaces is natuurlijk wel spannend...
>>     
>
> Niemand stopt je te gebruiken wat je wilt gebruiken, maar .NET en C#
> blijven Microsoft technologieën en mono zal waarschijnlijk altijd wel
> achter de feiten aan blijven lopen. Het enthousiasme om daarvan
> gebruik te maken zal in de Open Source gemeenschap niet erg groot
> zijn. Zeker niet nu java net onder de GPL vrijgegeven is.
>   
Dan is inderdaad zoals je stelt C++ of C het beste.

Omdat het bouwen van gui's in .net zo prettig werkt zou ik wel willen
kijken of er b.v. assembly wrappers om de C en C++ code heen kunnen
worden gebouwd. Vaak wordt hier SWIG voor gebruikt. M.a.w. bibliotheken
in C of C++, Gui's in .net, mono, gtk, qt etc. etc.

Zijn er nog meer mensen met ideeen? Ik waardeer deze discussie en vind
hem nu al erg nuttig!

> Jeroen Dekkers
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-nl/attachments/20070516/949e0efa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk-nl/attachments/20070516/949e0efa/attachment.pgp>


More information about the Talk-nl mailing list