<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Hi Peter<br><br>Ah yeah, That jar is a uk british national grid converter library which I am not sure I can make public at this time.<br>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. <br>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. <br><br>Regards<br>Stuart<br><br><div><hr id="stopSpelling">Date: Wed, 22 Oct 2014 22:32:09 +0200<br>From: graphhopper@gmx.de<br>To: graphhopper@openstreetmap.org<br>Subject: Re: [GraphHopper] Refactoring OSMReader process<br><br>
<div class="ecxmoz-cite-prefix">Hi Stuart,<br>
<br>
as said in the ticket: this is really great news!<br>
<br>
Regarding the problem: did you recreate the graph? In recent
version I renamed some options - see the changelog:<br>
<a class="ecxmoz-txt-link-freetext" href="https://github.com/graphhopper/graphhopper/blob/master/core/files/changelog.txt" target="_blank">https://github.com/graphhopper/graphhopper/blob/master/core/files/changelog.txt</a><br>
<br>
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:<br>
./graphhopper.sh import Initial/58096-SX9192-2c1.gz<br>
<br>
but got: <br>
"Could not find artifact
uk.co.ordnancesurvey.api:OSGBCoordinateConvertor:jar:1.0.3 in
central"<br>
<br>
> This means the parsing process is already 4 stage<br>
<br>
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:<br>
<br>
Regards,<br>
Peter.<br>
<br>
On 22.10.2014 22:00, Stuart Adam wrote:<br>
</div>
<blockquote cite="mid:DUB119-W4981FB08289302EDF86FB9BA950@phx.gbl">
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">As mentioned in comments about #269 I have been
working on implementing a reader for Ordnance Survey ITN roads
data.<br>
<br>
This has been based off the code of OSMReader and extracting
common interfaces.<br>
<br>
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.<br>
<br>
INFO: An exception was caught and reported. Message:
java.lang.IllegalStateException: Encoding does not match:<br>
Graphhopper config:
car:com.graphhopper.routing.util.CarFlagEncoder<br>
Graph: car|speedFactor=5.0|speedBits=5|turnCosts=false,
dir:examples/os-itn-sample-gh/<br>
java.lang.IllegalStateException: Couldn't load graph<br>
<br>
<br>
<br>
the code is available in engaric/graphhopper if anyone is
interested though it is still in an experimental shape at this
stage. <br>
Currently supported features :-<br>
<br>
1) Import of the basic road network<br>
2) Import of road names<br>
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.<br>
<br>
<br>
Work in progress<br>
1) Partial categorisation of road types to speed.<br>
2) One Way systems<br>
<br>
Work to be done<br>
1) Restrictions<br>
2) Conditional Restrictions<br>
3) Optimisation of the import process<br>
<br>
<br>
ITN is a copyright data set and not available as Ordnance Survey
opendata. However a sample file can be download from <br>
<br>
<a class="ecxmoz-txt-link-freetext" href="https://www.ordnancesurvey.co.uk/docs/sample-data/os-mastermap-itn-layer-sample-data.zip#sample-data-download" target="_blank">https://www.ordnancesurvey.co.uk/docs/sample-data/os-mastermap-itn-layer-sample-data.zip#sample-data-download</a><br>
<br>
The dataset is a Great Britain road coverage appropriate for car
navigation.<br>
<br>
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.<br>
<br>
<br>
Stuart Adam<br>
</div>
<br>
<fieldset class="ecxmimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
GraphHopper mailing list
<a class="ecxmoz-txt-link-abbreviated" href="mailto:GraphHopper@openstreetmap.org">GraphHopper@openstreetmap.org</a>
<a class="ecxmoz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/graphhopper" target="_blank">https://lists.openstreetmap.org/listinfo/graphhopper</a>
</pre>
</blockquote>
<br>
<br>_______________________________________________
GraphHopper mailing list
GraphHopper@openstreetmap.org
https://lists.openstreetmap.org/listinfo/graphhopper</div> </div></body>
</html>