<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Over 30seconds is **very** unusual for
this length. Going through entire Europe should be that range for
turn restrictions. E.g. going from Kiel to Freiburg is roughly the
same length and takes 1.5 second without turn instructions. So
with turn instructions should be like 3seconds for Germany, for
your use case even faster as the UK is 'width-limited' :)<br>
<br>
Did you try the unmodified GraphHopper master? Also make sure you
assign enough RAM to the JVM, that memory usage is the most
problematic downside of none-CH algorithms if you ask me.
Additionally we are working on none-CH algorithms where we'll get
faster calculation and less RAM in use.<br>
<br>
Regards,<br>
Peter<br>
<br>
<br>
On 24.11.2014 16:19, Stuart Adam wrote:<br>
</div>
<blockquote cite="mid:DUB119-W31C6A6E396002C2A782522BA720@phx.gbl"
type="cite">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">Hi Peter<br>
<br>
Speedwise with contraction hierarchies turned on the response is
almost instant. With it turned off in order to enable turnCosts
the service reaches the point where it doesn't reply quick
enough and the web demo times out, when routing from Scotland to
Hampshire.<br>
<br>
<br>
An example timing (probably not the Scotland example just the
most recent in my terminal window)<br>
<br>
time:229min, points:2895, took:31.092913, debug -
idLookup[0]:0.068101354s, [1] idLookup:0.12297253s,
algoInit:3.17604E-4s, dijkstrabi-routing:30.853657s, extract
time:0.00102621, simplify (6040->2895), , fastest, CAR<br>
<br>
<br>
Sincerely<br>
Stuart Adam<br>
<br>
<div>
<hr id="stopSpelling">Date: Mon, 24 Nov 2014 15:49:27 +0100<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:graphhopper@gmx.de">graphhopper@gmx.de</a><br>
To: <a class="moz-txt-link-abbreviated" href="mailto:graphhopper@openstreetmap.org">graphhopper@openstreetmap.org</a><br>
Subject: Re: [GraphHopper] Ordnance Survey Loader<br>
<br>
<div class="ecxmoz-cite-prefix">Hi Stuart, hi Philip,<br>
<br>
thanks for the insights! Also thanks Philip for the
suggestion!<br>
<br>
> Since once the import is done the graph is the same as
one imported from osm the query time code is unchanged nd so
should still be Java 6 compatible.<br>
<br>
I see. Then we should probably just make the module
separation and put all import stuff into another module or
tools. E.g. the web module is also java 7<br>
Also I'm not 100% sure if java 7 is that problematic as e.g.
Android development should be possible with java7 too I
think.<br>
<br>
<br>
> As commented by Philip Welch on here the simplest one's
to provide at runtime is either the hsqldb (remember to add
the hsql-jdbc driver lib as well)<br>
> or the wkt based one.<br>
<br>
Do you have a pom snippet at hand :) ?<br>
<br>
<br>
> (OSITN = too much block caps for my liking)<br>
<br>
me too but no problem - just wanted to mention it<br>
<br>
<br>
> The sample data actually requires a license agreement
so people should be directed to the website rather than
trying to automate via wget. <br>
> If it were not for that stage I would have placed the
sample data in git repo. I will try and negotiate for
permission to include it which would simplify that stage.<br>
<br>
We can also do this license agreement on the (bash) shell.<br>
<br>
<br>
> At the moment execution time without contraction
hierarchies (in order to support turn restrictions) <br>
> is very slow and so we would be interested in what work
is going on to combine the two and if there is any way we
can help<br>
<br>
What do you mean with 'very slow'? With turn restrictions it
should be like 2 times slower than without.<br>
<br>
Combining the both is no magic but requires some time to
work out the bits (although all the necessary steps are
already defined -> #270). And of course this is important
for us too but no starting date defined yet.<br>
<br>
Regards,<br>
Peter<br>
<br>
<br>
On 24.11.2014 14:52, Stuart Adam wrote:<br>
</div>
<blockquote
cite="mid:DUB119-W236892896F7777F57EA9CEBA720@phx.gbl">
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">HI Peter<br>
<br>
The logging is so heavy as we are still learning our way
around the api. Absolutely this should be reduced as time
goes on and there is already a number of test cases
specifically to do with os data. Unfortunately due to a
late change in coordinate convertor (ITN uses British
National Grid) some of these are currently broken. The
tests are almost certainly not as clean as they could be.
Only recently found the GraphInfo class that might help
some with that :-)<br>
<br>
I used reflection as that would enable us to more
dynamically extend the available readers but if it causes
problems with the iOS port then absolutely happy to change
that. iOS and android are important for us. The import
code at the moment takes advantage of String based
switches so is Java 7 specific. We can work on removing
that but for now have been relying on using desktop class
machines to pre import and then making the graph folder
available to client machines. Since once the import is
done the graph is the same as one imported from osm the
query time code is unchanged nd so should still be Java 6
compatible.<br>
<br>
Yes we will standardise the naming scheme. Relatively new
to git so was leaving such refactorings for now but was
already unhappy with my initial naming (OSITN = too much
block caps for my liking) <br>
<br>
The geotools supplies multiple different implementations
of the CRS lookup. As commented by Philip Welch on here
the simplest one's to provide at runtime is either the
hsqldb (remember to add the hsql-jdbc driver lib as well)
or the wkt based one. Only provide a single
implementation at runtime. Given the preferences of
deployment teams the actual implementation used wasn't
hardwired in to the build.<br>
<br>
The sample data actually requires a license agreement so
people should be directed to the website rather than
trying to automate via wget. If it were not for that
stage I would have placed the sample data in git repo. I
will try and negotiate for permission to include it which
would simplify that stage.<br>
<br>
At the moment execution time without contraction
hierarchies (in order to support turn restrictions) is
very slow and so we would be interested in what work is
going on to combine the two and if there is any way we can
help. <br>
<br>
Sincerely<br>
Stuart Adam<br>
<div>
<hr id="ecxstopSpelling">Date: Mon, 24 Nov 2014 12:26:31
+0100<br>
From: <a moz-do-not-send="true"
class="ecxmoz-txt-link-abbreviated"
href="mailto:graphhopper@gmx.de">graphhopper@gmx.de</a><br>
To: <a moz-do-not-send="true"
class="ecxmoz-txt-link-abbreviated"
href="mailto:graphhopper@openstreetmap.org">graphhopper@openstreetmap.org</a><br>
Subject: Re: [GraphHopper] Ordnance Survey Loader<br>
<br>
<div class="ecxmoz-cite-prefix">Hi Stuart,<br>
<br>
this is nice - thanks!<br>
<br>
I took a closer look at it. There seems to be an old
graphhopper.sh script? Also I had a problem with the
import when using the sample data you mentioned**<br>
<br>
What I did I described in the 'current instructions'
of the issue #227 and let us move the discussion to
it: <a moz-do-not-send="true"
class="ecxmoz-txt-link-freetext"
href="https://github.com/graphhopper/graphhopper/issues/277"
target="_blank">https://github.com/graphhopper/graphhopper/issues/277</a><br>
<br>
Let me know when you think that this is stable enough,
then we can work together on improving the abstraction
and refactoring mentioned in the notes, if you like.<br>
<br>
Kind Regards,<br>
Peter<br>
<br>
**<br>
org.opengis.referencing.NoSuchAuthorityCodeException:
No code "EPSG:27700" from authority "EPSG" found for
object of type "EngineeringCRS".<br>
at
org.geotools.referencing.factory.epsg.CartesianAuthorityFactory.noSuchAuthorityException(CartesianAuthorityFactory.java:136)<br>
at
org.geotools.referencing.factory.epsg.CartesianAuthorityFactory.createEngineeringCRS(CartesianAuthorityFactory.java:130)<br>
at
org.geotools.referencing.factory.epsg.CartesianAuthorityFactory.createCoordinateReferenceSystem(CartesianAuthorityFactory.java:121)<br>
at
org.geotools.referencing.factory.AuthorityFactoryAdapter.createCoordinateReferenceSystem(AuthorityFactoryAdapter.java:801)<br>
at
org.geotools.referencing.factory.ThreadedAuthorityFactory.createCoordinateReferenceSystem(ThreadedAuthorityFactory.java:731)<br>
at
org.geotools.referencing.DefaultAuthorityFactory.createCoordinateReferenceSystem(DefaultAuthorityFactory.java:179)<br>
at
org.geotools.referencing.CRS.decode(CRS.java:519)<br>
at
org.geotools.referencing.CRS.decode(CRS.java:447)<br>
at
uk.co.ordnancesurvey.api.srs.OpenCoordConverter.<clinit>(OpenCoordConverter.java:18)<br>
at
com.graphhopper.reader.osgb.OSITNNode.parseCoordinateString(OSITNNode.java:143)<br>
at
com.graphhopper.reader.osgb.OSITNNode.parseCoords(OSITNNode.java:131)<br>
at
com.graphhopper.reader.osgb.OSITNElement.handleCoordinates(OSITNElement.java:289)<br>
at
com.graphhopper.reader.osgb.OSITNElement.readTags(OSITNElement.java:89)<br>
at
com.graphhopper.reader.osgb.OSITNNode.create(OSITNNode.java:55)<br>
at
com.graphhopper.reader.osgb.OsItnInputFile.getNextXML(OsItnInputFile.java:209)<br>
at
com.graphhopper.reader.osgb.OsItnInputFile.getNext(OsItnInputFile.java:174)<br>
at
com.graphhopper.reader.osgb.OsItnReader.preProcessSingleFile(OsItnReader.java:294)<br>
at
com.graphhopper.reader.osgb.OsItnReader.preProcessSingleFile(OsItnReader.java:284)<br>
at
com.graphhopper.reader.osgb.OsItnReader.preProcessDirOrFile(OsItnReader.java:275)<br>
at
com.graphhopper.reader.osgb.OsItnReader.preProcess(OsItnReader.java:260)<br>
at
com.graphhopper.reader.osgb.OsItnReader.readGraph(OsItnReader.java:244)<br>
at
com.graphhopper.GraphHopper.importData(GraphHopper.java:634)<br>
at
com.graphhopper.GraphHopper.process(GraphHopper.java:603)<br>
at
com.graphhopper.GraphHopper.importOrLoad(GraphHopper.java:576)<br>
at
com.graphhopper.tools.Import.main(Import.java:16)<br>
Exception in thread "main" java.lang.RuntimeException:
Problem while parsing file<br>
at
com.graphhopper.reader.osgb.OsItnReader.preProcess(OsItnReader.java:262)<br>
at
com.graphhopper.reader.osgb.OsItnReader.readGraph(OsItnReader.java:244)<br>
at
com.graphhopper.GraphHopper.importData(GraphHopper.java:634)<br>
at
com.graphhopper.GraphHopper.process(GraphHopper.java:603)<br>
at
com.graphhopper.GraphHopper.importOrLoad(GraphHopper.java:576)<br>
at
com.graphhopper.tools.Import.main(Import.java:16)<br>
Caused by: java.lang.NullPointerException<br>
at
org.geotools.referencing.CRS.findMathTransform(CRS.java:1201)<br>
at
uk.co.ordnancesurvey.api.srs.OpenCoordConverter.toWGS84(OpenCoordConverter.java:30)<br>
at
com.graphhopper.reader.osgb.OSITNNode.parseCoordinateString(OSITNNode.java:143)<br>
at
com.graphhopper.reader.osgb.OSITNNode.parseCoords(OSITNNode.java:131)<br>
at
com.graphhopper.reader.osgb.OSITNElement.handleCoordinates(OSITNElement.java:289)<br>
at
com.graphhopper.reader.osgb.OSITNElement.readTags(OSITNElement.java:89)<br>
at
com.graphhopper.reader.osgb.OSITNNode.create(OSITNNode.java:55)<br>
at
com.graphhopper.reader.osgb.OsItnInputFile.getNextXML(OsItnInputFile.java:209)<br>
at
com.graphhopper.reader.osgb.OsItnInputFile.getNext(OsItnInputFile.java:174)<br>
at
com.graphhopper.reader.osgb.OsItnReader.preProcessSingleFile(OsItnReader.java:294)<br>
at
com.graphhopper.reader.osgb.OsItnReader.preProcessSingleFile(OsItnReader.java:284)<br>
at
com.graphhopper.reader.osgb.OsItnReader.preProcessDirOrFile(OsItnReader.java:275)<br>
at
com.graphhopper.reader.osgb.OsItnReader.preProcess(OsItnReader.java:260)<br>
... 5 more<br>
<br>
<br>
On 19.11.2014 00:08, Stuart Adam wrote:<br>
</div>
<blockquote
cite="mid:DUB119-W3911DBD014521749052905BA880@phx.gbl">
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">Hi All<br>
<br>
The dependency on internal code has been removed
from the OS ITN data loader by using geotools.<br>
This means you should be able to try it out now.
Some of the tests currently fail but the basics
work. To build you will want to skip the
acceptancetesting module, since that is an internal
test which will probably be moved out of this
repository as it is data dependant. For now skip
tests whilst I figure out what has broken the unit
tests, hopefully tomorrow.<br>
<br>
To run graphhopper loading itn files supply the
following configuration options<br>
<br>
<br>
osmreader.osm=<path to data file as normal but
this should be either a directory or itn xml file
rather than osm><br>
<br>
reader.implementation=com.graphhopper.reader.osgb.OsItnReader<br>
<br>
<br>
the reader.implementation setting changes which
DataReader implementation GraphHopper uses with
com.graphhopper.reader.osgb.OsItnReader and
com.graphhopper.reader.OSMReader now implementing an
interface DataReader. if reader.implementation is
not set com.graphhopper.reader.OSMReader is used by
default.<br>
<br>
osmreader.osm setting should probably change to
datareader.src with this change but for now I have
left that alone for compatibility reasons.<br>
<br>
Once the data is imported it can be used in a
standard GraphHopper server without having to switch
reader implementation which means ingested data
should work in a GraphHopper instance from the main
repo without consuming the engaric/graphhopper
branch though I believe at the moment I need to
resync with graphhopper/graphhopper repo as I
suspect the graph version has been changing rapidly
recently.<br>
<br>
Sincerely<br>
Stuart Adam<br>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
<br>
_______________________________________________
GraphHopper mailing list
<a class="moz-txt-link-abbreviated" href="mailto:GraphHopper@openstreetmap.org">GraphHopper@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/graphhopper">https://lists.openstreetmap.org/listinfo/graphhopper</a></div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
GraphHopper mailing list
<a class="moz-txt-link-abbreviated" href="mailto:GraphHopper@openstreetmap.org">GraphHopper@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/graphhopper">https://lists.openstreetmap.org/listinfo/graphhopper</a>
</pre>
</blockquote>
<br>
</body>
</html>