I've created a separate issue for this: https://github.com/graphhopper/graphhopper/issues/277
Feel free to comment or append to my minor task list etc! Regards, Peter. On 22.10.2014 23:51, me wrote: > 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 <[email protected]> > Date: > To: GraphHopper Java routing engine <[email protected]> > 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: [email protected] > To: [email protected] > 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 > [email protected] <mailto:[email protected]> > https://lists.openstreetmap.org/listinfo/graphhopper > > > > _______________________________________________ GraphHopper mailing > list [email protected] > https://lists.openstreetmap.org/listinfo/graphhopper > > > _______________________________________________ > GraphHopper mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/graphhopper
_______________________________________________ GraphHopper mailing list [email protected] https://lists.openstreetmap.org/listinfo/graphhopper
