[GraphHopper] Refactoring OSMReader process

[me]

Hi, 

Firstly its great news that someone is getting non-osm data into graphopper - well done!  (I'm uk based so this is particularly interesting to me). Secondly geotools supports BNG conversion so you should be able to use that as an alternative. I

Keep up the good work!

Phil Welch
www.opendoorlogistics.com


Sent from Samsung Mobile

-------- Original message --------
From: Stuart Adam <engaric at hotmail.com> 
Date:  
To: GraphHopper Java routing engine <graphhopper at openstreetmap.org> 
Subject: Re: [GraphHopper] Refactoring OSMReader process 
 
Hi Peter

Ah yeah, That jar is a uk british national grid converter library which I am not sure I can make public at this time.
I will see if I can find an alternate library that I can plugin for that purpose, unless there is already a dependency in the code base that can be used for this.  OSGBCoordinateConvertor is just what I have experience with. 
The graphhopper.sh import process probably won’t work as that still uses the original OSMReader not the alternate OsItnReader.  At the moment I have been using MiniItnGraphUI (which is based on MinGraphUI) as a trigger for importing the data into a graph as obviously it also allows me to visualise it when it completes.  Obviously a ReaderFactory or similar mechanism to switch between Reader implementations based on the supplied file/configuration options would be a reasonable idea. 

Regards
Stuart

Date: Wed, 22 Oct 2014 22:32:09 +0200
From: graphhopper at gmx.de
To: graphhopper at openstreetmap.org
Subject: Re: [GraphHopper] Refactoring OSMReader process

Hi Stuart,

as said in the ticket: this is really great news!

Regarding the problem: did you recreate the graph? In recent version I renamed some options - see the changelog:
https://github.com/graphhopper/graphhopper/blob/master/core/files/changelog.txt

Thanks also for pointing out to the sample data, that will be a good starting point for others like me to see the progress. How would a simple procedure be to get this working? I tried:
./graphhopper.sh import Initial/58096-SX9192-2c1.gz

but got: 
"Could not find artifact uk.co.ordnancesurvey.api:OSGBCoordinateConvertor:jar:1.0.3 in central"

> This means the parsing process is already 4 stage

Maybe you go via a 'lightweight' database or MapDB instead of reparsing? I once wanted to make this happening for OSM but due to lack of time I reprioritized:

Regards,
Peter.

On 22.10.2014 22:00, Stuart Adam wrote:
As mentioned in comments about #269 I have been working on implementing a reader for Ordnance Survey ITN roads data.

This has been based off the code of OSMReader and extracting common interfaces.

Due to its use of a modified version of the CarFlagEncoder until the recent updates I have been able to use a parsed ITN dataset as the working graph for an unmodified graphhopper web app. I hope to figure out where the incompatibility has arisen with the recent changes in the next few days. Error thrown during web app         start up follows.

INFO: An exception was caught and reported. Message: java.lang.IllegalStateException: Encoding does not match:
Graphhopper config: car:com.graphhopper.routing.util.CarFlagEncoder
Graph: car|speedFactor=5.0|speedBits=5|turnCosts=false, dir:examples/os-itn-sample-gh/
java.lang.IllegalStateException: Couldn't load graph



the code is available in engaric/graphhopper if anyone is interested though it is still in an experimental shape at this stage. 
Currently supported features :-

1) Import of the basic road network
2) Import of road names
3) Grade separation.  An interesting feature of the ITN dataset is that roads that pass over each other do have the crossing point listed as a node, so additional metadata must be parsed to separate the links.


Work in progress
1) Partial categorisation of road types to speed.
2) One Way systems

Work to be done
1) Restrictions
2) Conditional Restrictions
3) Optimisation of the import process


ITN is a copyright data set and not available as Ordnance Survey opendata.  However a sample file can be download from 

https://www.ordnancesurvey.co.uk/docs/sample-data/os-mastermap-itn-layer-sample-data.zip#sample-data-download

The dataset is a Great Britain road coverage appropriate for car navigation.

In some aspects the model of ITN can be compared to osm data, but in other areas it is modeled very differently.  This means the parsing process is already 4 stage rather than the current         osm preprocess/write 2 phase parse.  Some elements that in osm would be modeled on the way elements (from what I can see so far) are modeled on separate elements in ITN.


Stuart Adam


_______________________________________________
GraphHopper mailing list
GraphHopper at openstreetmap.org
https://lists.openstreetmap.org/listinfo/graphhopper


_______________________________________________ GraphHopper mailing list GraphHopper at openstreetmap.org https://lists.openstreetmap.org/listinfo/graphhopper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20141022/9bb83a19/attachment.html>