AlbertoZ
January 10th, 2008, 13:39
Do we really need vector maps for PSP MapThis!?
:confused:
Mapthis! and other navigation sw works (at the moment) with raster data (JPG, bitmap etc.). The idea could be to extract vector information from these data. The main limitation w.r.t. a commercial navigation software is the impossibility of *real-time* (it can be done easily off line using GMDL) creation of routes from a point A to a point B.
Hereafter is a possible, simple, workaround.
Motivations: unaccessibility/unavailability of free/available vector data for most of european countries, Italy included (where I live).
Problem statement: create an patway from A(lat,long) to B(lat,long) using MapThis-like sw (i.e.
without full vector information) in real-time.
Assumption: Geodata (set of coordinates like A[lat,long], where A could be any Point Of Interest,
address included) are supposed to be available.
Assume to have a jpg map (not necessarly at zoom level 1 but all the available strees must be on it).
The arc A(lat1,long1) to B(lat2,long2) (in first approximation a straight line) is the first guess of the pathway from A to B.
The next step is to create vector data from the jpg itself. Taking advantage of graphic libraries (I wander if) it is possible to extract the street contours (same colors: for example in google maps, “day mode”, main street are yellow, secondary streets dark grey etc.).
How:
1) "sample" the whole jpg with a fine enough grid of points.
2) Extract those points that belong to the street colours (example: in gimp/photoshop "Selection Instruments -> Selection by color"). - Cosine transforms of the image or other.…
(See second panel of figure attached)
3) interpolate/refine points to have a grid of straight lines (least squares methods).
(See third panel of figure attached)
4) Geolocate each straight line in the perimeter of the image:
- knowing the four vertices of the initial jpg (A1(latA1,longA1), A2(latA2,longA2), A3(latA3,longA3), A4(latA4,longA4)
- each street will have one (or more) lat-long vector.
At this point one could think of using already available algorithms for finding routes
between A and B using all the streets in format similar to
street 1: y = a1 * x + b1
street 2: y = a2 * x + b2
...
street n: y = an * x + bn
(see fourth panel of figure attached)
Of course this is just an initial idea for an algorithm and does not account for a large number of difficulties that can be encountered by getting vector street information from raster data. Anyone is aware of something similar ?
PS: probably nothing new under the Sun.
PS1: at the end,
GeoData + Raster Images != Vector Data
or better
GeoData + Raster Images ~ Vector Data
Just for fun,
;)
AlbertoZ
:confused:
Mapthis! and other navigation sw works (at the moment) with raster data (JPG, bitmap etc.). The idea could be to extract vector information from these data. The main limitation w.r.t. a commercial navigation software is the impossibility of *real-time* (it can be done easily off line using GMDL) creation of routes from a point A to a point B.
Hereafter is a possible, simple, workaround.
Motivations: unaccessibility/unavailability of free/available vector data for most of european countries, Italy included (where I live).
Problem statement: create an patway from A(lat,long) to B(lat,long) using MapThis-like sw (i.e.
without full vector information) in real-time.
Assumption: Geodata (set of coordinates like A[lat,long], where A could be any Point Of Interest,
address included) are supposed to be available.
Assume to have a jpg map (not necessarly at zoom level 1 but all the available strees must be on it).
The arc A(lat1,long1) to B(lat2,long2) (in first approximation a straight line) is the first guess of the pathway from A to B.
The next step is to create vector data from the jpg itself. Taking advantage of graphic libraries (I wander if) it is possible to extract the street contours (same colors: for example in google maps, “day mode”, main street are yellow, secondary streets dark grey etc.).
How:
1) "sample" the whole jpg with a fine enough grid of points.
2) Extract those points that belong to the street colours (example: in gimp/photoshop "Selection Instruments -> Selection by color"). - Cosine transforms of the image or other.…
(See second panel of figure attached)
3) interpolate/refine points to have a grid of straight lines (least squares methods).
(See third panel of figure attached)
4) Geolocate each straight line in the perimeter of the image:
- knowing the four vertices of the initial jpg (A1(latA1,longA1), A2(latA2,longA2), A3(latA3,longA3), A4(latA4,longA4)
- each street will have one (or more) lat-long vector.
At this point one could think of using already available algorithms for finding routes
between A and B using all the streets in format similar to
street 1: y = a1 * x + b1
street 2: y = a2 * x + b2
...
street n: y = an * x + bn
(see fourth panel of figure attached)
Of course this is just an initial idea for an algorithm and does not account for a large number of difficulties that can be encountered by getting vector street information from raster data. Anyone is aware of something similar ?
PS: probably nothing new under the Sun.
PS1: at the end,
GeoData + Raster Images != Vector Data
or better
GeoData + Raster Images ~ Vector Data
Just for fun,
;)
AlbertoZ