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]
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
