GeoData + Raster Images = Vector Data ?

[AlbertoZ]

Do we really need vector maps for PSP MapThis!?



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

[Nieko]

Nice idea, but probably difficult (computationally also), and I foresee at leasth one problem. Some streets intersect at different levels (viaduct), streets would end here.

[AlbertoZ]

Hi Nieko,

yes, I also have the suspect that this is computationally intensive and far from being efficient or perfect.
Intersections of routes in viaducts is one of the evident problems as you correctly point out. Also one-way streets
etc.

Just a think...
By the way, I think that pattern recognition from raster
is not new at all, I just wander if this was anyway applied to the GPS navigation field in some way...

Best,

AlbertoZ