[GraphHopper] Refactoring OSMReader process

Wed Oct 29 20:50:34 UTC 2014

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 <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 <mailto:GraphHopper at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/graphhopper
>
>
>
> _______________________________________________ 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/20141029/03b6ceab/attachment.html>