Mapwindow (GIS)

Hoi Weerman,

Ik heb http://www.mapwindow.org kunnen compileren met vs2005. Eerst de fouten er uit gehaald. Mapwindow gebruikt het project http://www.gdal.org/ , dus met de aanwijzingen van BuildingOnWindows – GDAL gecompileerd.

Om de laatste fouten (externe procedures an hij niet vinden) moet je oplossen door de library ‘gdal.lib’ van mapwindow te overschrijven met de library ‘gdal.lib’ van het project gdal.
Mapwindow levert een file op genaamd MapWinGIS.ocx Deze file kan je in het voorbeeld project http://www.mapwindow.org/samples/VC++6_SampleCode.zip meecompileren.

Weerman, Ik heb niet zoveel kennis van de “ocx technieken”. Ik zie bij “VC++6_SampleCode” een soort land met provincien, waarbij je kan inzoomen.

De hartelijke groet Jan Marco

Het ‘hardgecodeerde’ pad naar de meegekomen
Shapefile - Wikipedia][i]“shape”[/i
-bestanden veranderen naar die van kaarten die je interesse wel hebben?

Bijvoorbeeld van jouw woonplaats? Maakt deel uit van data voor “Nederland” (AND via
http://www.opengeodata.org/images/2007/AND/AND-NL.tar.gz]OSM
) met buurt- en wijkgrenzen uit de “Wijk- en buurtkaart 2006” (CBS) en “Begrenzing Bebouwd Gebied 2003” (VROM), hier respectievelijk in zwart, iets van paars of is dat bordeaux, groen en oranje:

Wat betreft de laatstgenoemde gegevens, weet niet of dit nog geldt:

Provincies in Afghanistan? De insteek is hier eigenlijk
http://pubs.usgs.gov/of/2006/1179/Data_layers.html][i]“Petroleum Resource Potential”[/i
:

      databestanden http://img65.imageshack.us/img65/3291/afghanistanct7.gif][img]http://img65.imageshack.us/img65/3291/afghanistanct7.th.gif[/img]
Bij de [url=http://pubs.usgs.gov/of/2006/1179/shapes[/url] in 'shp'-formaat voor de laatstgenoemde kaart staan ook [i]"Large rivers"[/i] en [i]"Rivers"[/i]. Deze als 'layers' toevoegen geeft een behoorlijk met water dooraderde indruk van Afghanistan, nooit geweten:
      http://img65.imageshack.us/img65/3476/hydrolafgct1.jpg][img]http://img65.imageshack.us/img65/3476/hydrolafgct1.th.jpg[/img

Hoi Weerman,

Ik zie ook dat de client “VC++6_SampleCode” programma van mapwindow ook afhankelijk is van (opensource programma) proj.dll van http://proj.maptools.org/

In het client programma heb ik 1 of meerdere van de vier shapes vervangen door de databestanden die jij hebt gegeven. Ik zie dan Afghanistan en Nederland in 1 window. Als je dan op Nederland inzoomt dan zie je bijvoorbeeld de gemeentes.

Het mooie plaatje van mijn woonplaats heb ik nog niet op scherm gekregen.

Het programma doet mij veel denken aan de vector kaartprogramma van een vorige cdfoonleverancier.

De hartelijke groet Jan Marco

P.S. Het is mijn intentie om mapwindow in sqlyog client onder te brengen. Ik weet niet wat het voordeel/nadeel van OLE custom controls (OCX) is. Zie ook Object Linking and Embedding - Wikipedia
De shape files daarbij in mysql (blobveld) gaan zetten.

Hoi Weerman,

Ik wil Mapwindow gebruiken om de shape-files in mysql in te laden. Als je de shapes van de woonplaatsen van Nederland in Mysql zet kan je de wegsegmenten goed op ‘woonplaats’ zetten.

Vandaag even zitten zoeken naar de libraries waar Mapwindow van afhankelijk is. Ik kan de source van siapp.lib en spwmath.lib van 3dconnexionsdk niet zo gauw vinden. Het wel of niet kunnen vinden van source heeft geen relatie met het wel of niet kunnen inladen in mysql. Ik dacht om Mapwindow naast sqlyog te positioneren. Een soort viewer van shapefiles te maken. Als ik het door heb hoe het werkt en voldoende source aanwezig zou je kunnen proberen om het te gaan integreren (mapwindow + sqlyog).

De hartelijke groet Jan Marco

Hoi Weerman,

Weer wat beter naar de Mapwindow-applicatie gekeken. Ze gaan met procedures naar de interne procedures van Explorer toe. Mogelijk kan je de bovenkant afbuigen naar Firefox routines. De onderliggende GIS routines zijn erg interessant om in het project op te nemen.

Ben net weer begonnen om de NMEA-parser in gewoon C om te zetten. Hierna in de scheduler gaan hangen. Je kan dan straks automatisch in MySQL de coordinaten van een GPS-device (GPS-mouse o.i.d) opslaan. Je rijdt in de auto met een laptop naar een plaats en alle GPS-coordinaten worden in MySQL opgeslagen. Men kan dan extra info aan de wegsegmenten-tabel toevoegen. Je zou ook een webcam op ppc kunnen aansluiten en dan de beelden van de route kunnen opslaan. Later virtueel de route weer kunnen gaan rijden.

De hartelijke groet Jan Marco

P.S. In http://www.codeproject.com/KB/mobile/WritingGPSApplications2.aspx staat info hoe het met de GPS-satelieten werkt.

Dan wil OpenStreetMap

graag je ‘traces’ hebben.

Nog even over dat plaatsen toevoegen, bedoel je met “wegsegmenten” de gegevens van wegen en straten die van de Telefoongids-CD gehaald
http://www.foondump.nl/forum/viewtopic.php?p=3121#3121
kunnen worden? In dat geval, op die CD heeft TravelManager voor Nederland meer dan anderhalf miljoen segmenten van Falkplan-Andes meegekregen. Wil je dan aan elk daarvan een van de zeg 2500 plaatsnamen hangen dan moet je iets met het enorme “cartesisch product” van die wegen en plaatsen en hun reeksen coordinaten. Je zoekt dan een relatie, nee? Daarvoor zou je bijvoorbeeld datzelfde grid kunnen gebruiken dat ook voor het inwinnen van de gegevens ingezet kon worden, daarmee maak je het selectiever:

[code]INSERT INTO blok_plaats
SELECT blok, plaats
FROM plaatsen
JOIN rasterblokken
ON plaatsen.geom.STIntersects(rasterblokken.geom)=1

INSERT INTO straat_plaats
SELECT straat, plaats
FROM straten
INNER JOIN blok_plaats
ON straten.blok = blok_plaats.blok
INNER JOIN plaatsen
ON blok_plaats.plaats = plaatsen.plaats
AND straten.geom.STWithin(plaatsen.geom) = 1[/code]
Uit het blote hoofd maar je snapt wat ik bedoel.

Even gekeken, in het aan OSM gedoneerde bestand
http://www.opengeodata.org/images/2007/AND/AND-NL.tar.gz
van AND-Nederland zit ook een aantal shape-bestanden met provincies, gemeenten en plaatsen. In “020_c.shp” zitten meer dan 5500 plaatsnamen met oa. “Zuiveringsinst” en ook “Zwarte Haan”, “Zwarte Paard” en “Zwarte Ruiter”. Het is nog de vraag hoe bruikbaar het dan is, de enige “paarden” die de plaatsnamenlijst van het postcodeboek heeft zijn “Witte Paarden” (“8335 LK” en “-LL”). Dat is meteen ook zowel de straatnaam als de woonplaats dus niemand gelooft je als je zegt dat je daar woont. Als je daar al woont, zie maar es een hypotheek te krijgen met zo’n adres. De “vlakken” voor “plaatsen” hebben meer “bebouwde kom”-contouren dan administratieve omtrekken zo te zien.

Nog even terug naar “in welke plaats ligt een straat”, je zal met een residu blijven zitten, een rest van segmenten die aan twee of meer plaatsen toegeschreven kunnen worden, daar heb je vervolgens weer “STIntersects(plaatsen)” voor nodig ipv. “STWithin(plaatsen)”.

Tot het moment dat je jezelf een eigen shapeviewer gebouwd hebt, bijvoorbeeld hier
http://www.element.nl/gis/downloads/Proviewer90.exe
staat de viewer van MapInfo, waarmee je ook shp-bestanden kan openen.

Hoi Weerman,

Ik heb 2.641.732 wegsegmenten van de TravelManager kunnen halen. Wegsegment zie ik analoog aan een lijnsegment, echter lijn is feitelijk een ‘weg’. Een wegsegment kan je m.i. altijd wel in 1 plaats laten vallen. Mocht wegsegment in twee plaatsen liggen dan wegsegment gaan opknippen in twee stukken. Door het in wegsegment (MySQL tabel) formaat op te slaan kan je gemakkelijk op een knooppunt zien waar je heen kan gaan, door een select commando op de database te geven.

Een (woon)plaatsshape bestand zal wel uit N punten bestaan die de shape vormen. M.i. kan je alle punten wel in geheugen gaan laden. Hierna gaan checken of ze in de shape liggen. Als je een vierkant om de woonplaats shape legt, kan je gemakkelijk een simpele test doen of hij zeker niet in het vierkantje ligt of niet. Ligt hij er wel in dan feitelijk alle punten van de shape (in memory) nalopen. N.B. Een vierkantje vind je door min/max van de shape punten te berekenen/sorteren.

De hartelijke groet Jan Marco

Ok, ok, respect, maar kunnen wij misschien toch heel even onze klokjes gelijk zetten?

Dat we zeggen, een wegsegment is een polyline door twee of meer punten die van Falkplan of liever van Andes - want daar komt TravelManager oorspronkelijk toch vandaan - een uniek nummer meegekregen heeft, in TMC-speak een “ChainID”?

En al zijn dat nog zoveel punten, dus waar ie doorheenloopt, het is en blijft één enkele polyline? Daarentegen, hun wegen en straten kunnen vanwege zijstraten of een kruising voor de kaart samengesteld zijn uit meer dan één polyline, allemaal met dezelfde straatnaam maar met verschillende chainid’s?

Bijvoorbeeld degene met de meeste punten (49) die je eruit
http://www.foondump.nl/forum/viewtopic.php?p=3121#3121
krijgt heeft chainid 1411279610, is onderdeel van de “Spijkerboersweg”. Er zijn twee chains met de straatnaam “Spijkerboersweg”, de andere “Spijkerboersweg” heeft 14 knikken en twee eindpunten, 15 van jouw lijnstukken dus, is door Falkplan-Andes de wereld ingestuurd als één polyline en in feite maar een halve straat:

chainid straatnaam plaats 1411279610 Spijkerboersweg KAMPERVEEN 1423272698 Spijkerboersweg KAMPERVEEN
Met als bijzonderheid een knooppunt dat daar voor een keer niet inzit vanwege een kruising of een zijstraat, de beide helften van deze “Spijkerboersweg”, ‘chains’ dus, vertegenwoordigen samen een doorgaande weg zonder zijstraten of kruisingen.

Doorgaans is dat wel zo omdat het hier gaat om een routeplanner, het gaat om de knopen, dat is ook de reden dat ze de trajecten van veerboten als “wegsegmenten” opgenomen hebben, dan kunnen die meegerouterd worden. Daarom was uiteindelijk ook het “beentje-over”-scannen van de TMC-data op de Telefoongids-CD zo effectief, alles zit aan alles vast juist vanwege dat route-netwerk.

Ja en nee:

[quote]A polygon search has a more complex algorithm. The basic algorithm consists of using a line that goes through a data point. Once this line is calculated, the number of points of intersection with the polygon sides is counted on both the left and right side. If there is an odd number of intersecting points on the right side and odd number of intersecting points on the left side then the data point is inside the polygon:

    [img]http://i.msdn.microsoft.com/Cc451895.ef7ce653-191e-4168-8a6a-c0eda05865da(en-us,MSDN.10).png[/img]
If there is an even number of points of intersection on either side of the data point then data point is outside of the polygon:
    [img]http://i.msdn.microsoft.com/Cc451895.cea1fa1f-2878-4fc3-9e6a-5bf7adc0b9b3(en-us,MSDN.10).png[/img]
Note that it really doesn’t matter where you draw the line as any line will eventually intersect the polygon.

Microsoft-MSDN: Bounding Box, Radius, and Polygon Search

[/quote]

Hoi Weerman,

Op de site site/forum Berekenen of coordinaten binnen een polygoon liggen * - Softwareontwikkeling - GoT probeert men ook een methode te vinden of coordinaat in een polygoon ligt. Jouw methode van snijpunten bepalen lijkt mij simpeler.

De hartelijke groet Jan Marco

wh wrote:

[quote]Dus heb je een functie nodig:

Vind_snijpunt(lijnstuk, positie)

Lijnstuk bestaat uit 2 punten (begin en eind)

Positie is de punt die we willen weten of die binnen een polygoon ligt.
Creëer een horizontale lijn.

De functie Vind_snijpunt geeft het snijpunt terug als die bestaat voor het lijnstuk met de horizontale lijn; anders een empty resultaat;

Sorteer alle lijnstukken van de polygoon En vind alle snijpunten Sorteer die naar links/rechts van de positie. Bepaal of die in de polygoon ligt.

Goede tip van die weerman![/quote]

In functies zitten m.i. ook in MapWindow, namelijk pointInPolygon() en OGRPointInRing(). Laatste zit in de onderliggende gdal library.

Hoi Weerman,

[quote],maar kunnen wij misschien toch heel even onze klokjes gelijk zetten?

Dat we zeggen, een wegsegment is een polyline door twee of meer punten die van Falkplan of liever van Andes - want daar komt TravelManager oorspronkelijk toch vandaan - een uniek nummer meegekregen heeft, in TMC-speak een “ChainID”? [/quote]

[quote]http://wiki.openstreetmap.org/index.php/Nl:FAQ
Waarom is een segment soms onderdeel van meer dan één weg?
Segmenten kunnen onderdeel zijn van meer wegen omdat het de omvang van de database kan beperken. Het is een manier om bestaande data te hergebruiken.

Zoiets is relevant in de volgende situatie: stel je een “logische” weg voor die een spoorlijn voorstelt, een andere “logische” weg die een voetpad voorstelt, en een ander stuk weg. Al deze wegen kunnen in werkelijkheid samenvallen. De wegen zullen uiteraard verschillen in meta-data (tags) terwijl ze de segmenten delen. Dit bespaart ruimte in de database. [/quote]

Ik denk dat jij chain (=ketting) als wegsegment ziet. Ik zie een wegsegment als een logische weg tussen twee punten. Ik begrijp niet zo waarom TMC chain gebruikt. Ik weet wel dat reistijd en reisafstand geldt over een chain en niet verdeeld is over de lijnstukken tussen de punten. Een chain zou m.i. waarde kunnen hebben als de volgorde waarin je het parcour moet afleggen belangrijk is.

De hartelijke groet Jan Marco

Appendix MySQL structuur van wegsegment. N.B. PlaatsDB=plaats Dichts Bijzijnde. De specifieke plaats bij wegsegment met de shape bestanden van de 2500 plaatsen in Nederland gaan bepalen.

[quote]create table wegSegment (
ts timestamp,
id bigint(16) unsigned not null,
plaats varchar(255) not null default’‘,
plaatsDB varchar(255) not null default’‘,
straat varchar(255) not null default’‘,
wegNummer varchar(16) not null default’‘,
wegNummerEU varchar(16) not null default’‘,
afslag varchar(16) not null default’‘,
chainId bigint(16) not null default -1,
chainSeq bigint(16) not null default -1,
rijRichting varchar 16) not null default’‘,
type varchar(32) not null default’‘,
rdXA double not null default 0,
rdYA double not null default 0,
rdXB double not null default 0,
rdYB double not null default 0,
latitudeA double not null default 0,#Latitude - Wikipedia
longitudeA double not null default 0,#Longitude - Wikipedia
latitudeB double not null default 0,#Latitude - Wikipedia
longitudeB double not null default 0,#Longitude - Wikipedia
reisAfstand bigint(16) not null default -1,
reisTijd bigint(16) not null default -1,
richting varchar(255) not null default’‘,
richtingAB varchar(255) not null default’‘,
richtingBA varchar(255) not null default’',
index (plaats(16)),
index (plaatsDB(16)),
index (straat(16)),
index (wegNummer(8 )),
index (wegNummerEU(8 )),
index (afslag(8 )),
index (chainId),
index (chainSeq),
index (rijRichting(8 )),
index (type(8 )),
index (rdXA,rdYA),
index (rdYA),
index (rdXB,rdYB),
index (rdYB),
index (latitudeA,longitudeA),
index (longitudeA),
index (latitudeB,longitudeB),
index (longitudeB),
index (reisAfstand),
index (reisTijd),
index (richting(16)),
index (richtingAB(16)),
index (richtingBA(16)),
index (ts),
primary key (id)
) type=myisam; [/quote]