Re: [mkgmap-dev] line features are converted to a closed way
On Mon, Sep 20, 2010 at 1:52 PM, wrote: > Personally, I would love it if some logic could be added to mkgmap for > it to be able to detect whether something is a closed polygon or not, > which would make it much more robust in these instances. Right, I think coastline does this already, because, log errors reports non-closed coastlines. Or, simply disregard non-closed ways that are included in the polygons style files. -- cheers, maning -- "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] STOP signs and routing
Hello, Does mkgmap support STOP or GIVE-Way signs for routing? It is acutally interesting to know if the calculated route will bring you in front of a STOP... If the sings are tagged like described here http://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop "As nodes on the ways approaching intersections" it would be possible to create two ways in opposite direction, both with oneway=yes, and different values for maxspeed. The way in direction of the main road could be set to 1 or 2 km/h, so it will cost a couple of extra seconds for the routing algorithm. If the original road is already oneway=yes, no opposite way has to be created, otherwise the original oneway=yes will loose its effect... What do you thing about this? Kindly Hendrik ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] STOP signs and routing
A thread for improving routing gave this suggestion in the points style.
highway=traffic_signals { add mkgmap:road-speed = '-2'; add
mkgmap:road-speed-min = '1' }
highway=crossing { add mkgmap:road-speed = '-1'; add
mkgmap:road-speed-min = '1' }
highway=stop { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' }
traffic_calming=* { add mkgmap:road-speed = '-2'; add
mkgmap:road-speed-min = '1' }
barrier=toll_booth { add mkgmap:road-speed = '-2'; add
mkgmap:road-speed-min = '1' }
The reduces the road speed of the way with the traffic_signal node.
I haven't tested fully but it seems to improve time calculation.
On Mon, Sep 20, 2010 at 6:31 PM, Hendrik Oesterlin
wrote:
> Hello,
>
> Does mkgmap support STOP or GIVE-Way signs for routing? It is
> acutally interesting to know if the calculated route will bring you in
> front of a STOP...
>
> If the sings are tagged like described here
> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop "As nodes on the
> ways approaching intersections" it would be possible to create two
> ways in opposite direction, both with oneway=yes, and different values
> for maxspeed. The way in direction of the main road could be set to 1
> or 2 km/h, so it will cost a couple of extra seconds for the routing
> algorithm.
>
> If the original road is already oneway=yes, no opposite way has to be
> created, otherwise the original oneway=yes will loose its effect...
>
> What do you thing about this?
>
> Kindly
> Hendrik
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
--
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
wiki: http://esambale.wikispaces.com/
blog: http://epsg4253.wordpress.com/
--
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] STOP signs and routing
On 09/20/2010 01:43 PM, maning sambale wrote:
> A thread for improving routing gave this suggestion in the points style.
>
> highway=traffic_signals { add mkgmap:road-speed = '-2'; add
> mkgmap:road-speed-min = '1' }
> highway=crossing { add mkgmap:road-speed = '-1'; add
> mkgmap:road-speed-min = '1' }
> highway=stop { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1' }
> traffic_calming=* { add mkgmap:road-speed = '-2'; add
> mkgmap:road-speed-min = '1' }
> barrier=toll_booth { add mkgmap:road-speed = '-2'; add
> mkgmap:road-speed-min = '1' }
>
> The reduces the road speed of the way with the traffic_signal node.
> I haven't tested fully but it seems to improve time calculation.
I have tested it. There seems to be two major problems with that. First
of all, it lowers the speed of the segment that has the poi. Lenght of
that segment is sometimes just a few meters, sometimes a long road.
So, it is more or less based on luck, whether the calculation of time is
better or not. In any case, the time calculated should be longer.
Matters could be improved by for example making an automatic split for a
road if the segment containing speed-lowering poi gets too long.
Another problem is with Garmin routing. I'd be more interested in
avoiding the low-speed points. However, Garmin does not use road speed
too intelligently. Instead it seems to calculate the route based on
road_class mostly.
--
Harri
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] line features are converted to a closed way
char...@cferrero.net schrieb am 20.09.2010 07:52: > Personally, I would love it if some logic could be added to mkgmap for > it to be able to detect whether something is a closed polygon or not, > which would make it much more robust in these instances. I would also like to see such a feature, perhaps implemented via a command line switch. The problem occurs for me, when I want to display access restrictions on my map. access=* can be placed on any area element (e.g. amenity=parking) or it can be placed on any line element e.g. highway=* Right now there is no way to tell mkgmap, that the polygon rules shall not be applied to the line elements. If the polygon rules could be limited to closed polygons only, than this problem would not be solved completely but to a very large degree. (There can still be line elements forming a closed loop.) Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] problem with mkgmap r1699
Moin, I have a problem with mkgmap version r1699: it crashes while generating my maps. With r1673 everything was ok. It does not seem to be related to the style, I tried different layers of my maps and all are crashing. I use the following mkgmap command line and get this error message: java -jar -Xmx6144M ../../mkgmap-r1699/mkgmap.jar --style-file=../../styles/09_maxspeed --remove-short-arcs=5 --transparent --family-id=49 --country-name="Deutschland" --country-abbr="D" --overview-name="Tempolimits" --family-name="Tempolimits" --series-name="Tempolimits" --description="Tempolimits" --tdbfile --draw-priority=23 --max-jobs=3 -c maplist.txt java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:547) at java.util.ArrayList.get(ArrayList.java:322) at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.processEle (MultiPolygonRelation.java:818) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.endRelation( mlHandler.java:620) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.endElement(O lHandler.java:590) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.end nt(AbstractSAXParser.java:601) at com.sun.org.apache.xerces.internal.xinclude.XIncludeHandler.endE t(XIncludeHandler.java:1014) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScann l.scanEndElement(XMLDocumentFragmentScannerImpl.java:1774) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScann l$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2930) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.n MLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl (XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScann l.scanDocument(XMLDocumentFragmentScannerImpl.java:510) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.pa ML11Configuration.java:807) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.pa ML11Configuration.java:737) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLPa java:107) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.par stractSAXParser.java:1205) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXPar arse(SAXParserImpl.java:522) at javax.xml.parsers.SAXParser.parse(SAXParser.java:395) at javax.xml.parsers.SAXParser.parse(SAXParser.java:198) at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5 taSource.java:84) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:1 at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:189) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:186) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:30 at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoo utor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExe .java:907) at java.lang.Thread.run(Thread.java:619) Exiting - if you want to carry on regardless, use the --keep-going option Gruss Torsten ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] --transpatent not work
Hi! I create map (contour) with: mkgmap --gmapsupp --tdbfile \ --family-name="NASA-SRTM-Topo" \ --product-id=9 \ --family-id=99 \ --series-name="Vyatka-topo" \ --description="Centae" \ --country-name="RUSSIA" --country-abbr="RU" \ --charset=cp1251 --lower-case \ --style-file=stranger/ \ --output-dir=elev/ \ --draw-priority=31 \ --transpatent \ elev/*.osm \ topo.TYP But map not transparent. In GMapTool i see that map not have T flag. I test in in 1673 and 1699. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --transpatent not work
Maks Vasilev (m...@stranger-team.ru) wrote: > Hi! > > I create map (contour) with: > > mkgmap --gmapsupp --tdbfile \ > --family-name="NASA-SRTM-Topo" \ > --product-id=9 \ > --family-id=99 \ > --series-name="Vyatka-topo" \ > --description="Centae" \ > --country-name="RUSSIA" --country-abbr="RU" \ > --charset=cp1251 --lower-case \ > --style-file=stranger/ \ > --output-dir=elev/ \ > --draw-priority=31 \ > --transpatent \ > elev/*.osm \ > topo.TYP > > But map not transparent. In GMapTool i see that map not have T flag. > I test in > in 1673 and 1699. > ___ Hi, It's --transparent, not --transpatent -- Charlie ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --transpatent not work
OMG! sorry :( В сообщении от Понедельник 20 сентября 2010 21:49:03 автор char...@cferrero.net написал: > Maks Vasilev (m...@stranger-team.ru) wrote: > > Hi! > > > > I create map (contour) with: > > > > mkgmap --gmapsupp --tdbfile \ > > > > --family-name="NASA-SRTM-Topo" \ > > --product-id=9 \ > > --family-id=99 \ > > --series-name="Vyatka-topo" \ > > --description="Centae" \ > > --country-name="RUSSIA" --country-abbr="RU" \ > > --charset=cp1251 --lower-case \ > > --style-file=stranger/ \ > > --output-dir=elev/ \ > > --draw-priority=31 \ > > --transpatent \ > > elev/*.osm \ > > topo.TYP > > > > But map not transparent. In GMapTool i see that map not have T flag. > > > > I test in > > > > in 1673 and 1699. > > ___ > > Hi, > > It's --transparent, not --transpatent ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] basic search
What way to create basic address and POI search in map created with mkgmap? OSM data have tag in addr:* shema (http://wiki.openstreetmap.org/wiki/Key:addr), map created with --make-poi- index and --index, but search in garmin not work. -- wbr, Maks ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --transpatent not work
On Mon, Sep 20, 2010 at 10:15:58PM +0400, Maks Vasilev wrote: >OMG! sorry :( But you could rightfully complain that mkgmap silently ignores unknown command line switches. As far as I understand, the problem is that there is no centralized command line parsing. Each code snippet looks for its own magic parameter among all command line options. One thing that could be done is to set a flag whenever an option gets processed. Then, at the end of the run, mkgmap could list the ignored options. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problem with mkgmap r1699
Hi Torsten,
I can confirm that this is a problem of the MultiPolygon code that has
been changed with r1694. Attached patch fixes that.
But I am not sure in what situations the bug happens. Could you do me a
favour and run mkgmap with the following log.properties file?
===
.level=SEVERE
handlers: java.util.logging.FileHandler
java.util.logging.FileHandler.level=FINE
java.util.logging.FileHandler.formatter=uk.me.parabola.log.UsefulFormatter
java.util.logging.FileHandler.limit=100
java.util.logging.FileHandler.count=4
java.util.logging.FileHandler.pattern=mkgmap.log
java.util.logging.FileHandler.append=false
uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.level=FINE
===
Please run it without the --keep-going option and send me the logfile
with the exception which should be mkgmap.log.0. Thanks!
WanMil
Moin,
I have a problem with mkgmap version r1699: it crashes while generating my maps.
With r1673 everything was ok.
It does not seem to be related to the style, I tried different layers of my maps
and all are crashing.
I use the following mkgmap command line and get this error message:
java -jar -Xmx6144M ../../mkgmap-r1699/mkgmap.jar
--style-file=../../styles/09_maxspeed --remove-short-arcs=5 --transparent
--family-id=49 --country-name="Deutschland" --country-abbr="D"
--overview-name="Tempolimits" --family-name="Tempolimits"
--series-name="Tempolimits" --description="Tempolimits" --tdbfile
--draw-priority=23 --max-jobs=3 -c maplist.txt
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.processEle
(MultiPolygonRelation.java:818)
at uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.endRelation(
mlHandler.java:620)
at uk.me.parabola.mkgmap.reader.osm.xml.Osm5XmlHandler.endElement(O
lHandler.java:590)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.end
nt(AbstractSAXParser.java:601)
at com.sun.org.apache.xerces.internal.xinclude.XIncludeHandler.endE
t(XIncludeHandler.java:1014)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScann
l.scanEndElement(XMLDocumentFragmentScannerImpl.java:1774)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScann
l$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2930)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.n
MLDocumentScannerImpl.java:648)
at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl
(XMLNSDocumentScannerImpl.java:140)
at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScann
l.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.pa
ML11Configuration.java:807)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.pa
ML11Configuration.java:737)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLPa
java:107)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.par
stractSAXParser.java:1205)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXPar
arse(SAXParserImpl.java:522)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:198)
at uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5
taSource.java:84)
at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:1
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:189)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:186)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:30
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoo
utor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExe
.java:907)
at java.lang.Thread.run(Thread.java:619)
Exiting - if you want to carry on regardless, use the --keep-going option
Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java (revision 1699)
+++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java (working copy)
@@ -813,11 +813,14 @@
if (currentPolygon.outer && outmostPolygonProcessing) {
// this is the outmost polygon - copy its tags. They will be used
// later for tagging of the lines
- assert singularOuterPolygons.size
Re: [mkgmap-dev] basic search
On Mon, Sep 20, 2010 at 10:24:55PM +0400, Maks Vasilev wrote: >What way to create basic address and POI search in map created with mkgmap? > >OSM data have tag in addr:* shema >(http://wiki.openstreetmap.org/wiki/Key:addr), map created with --make-poi- >index and --index, but search in garmin not work. Which Garmin? The Edge 705, GPSMap 60CSx and possibly many older models do not need either option. As far as I understand, the mkgmap --index option produces "half-cooked" files that must be transferred by MapSource to the device. Once that is done, the search should work. Others can hopefully chime in; I have never used MapSource. Best regards, Marko ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] line features are converted to a closed way
The coastline log errors come from the special coastline handling which
has nothing in common with the described problem.
Attached patch performs only the line styles on unclosed ways (the patch
is untested!!).
Please consider the following:
1. Line rules must be performed on polygons (==closed ways). Otherwise
all roundabouts and other circular streets will disappear.
2. Due to the tile splitter lots of polygons on the tile border might
not be completely contained in the tile. I'm not sure if these ways are
closed or not.
WanMil
On Mon, Sep 20, 2010 at 1:52 PM, wrote:
Personally, I would love it if some logic could be added to mkgmap for
it to be able to detect whether something is a closed polygon or not,
which would make it much more robust in these instances.
Right, I think coastline does this already, because, log errors
reports non-closed coastlines.
Or, simply disregard non-closed ways that are included in the polygons
style files.
Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 1699)
+++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy)
@@ -283,7 +283,7 @@
preConvertRules(way);
Rule rules;
- if ("polyline".equals(way.getTag("mkgmap:stylefilter")))
+ if ("polyline".equals(way.getTag("mkgmap:stylefilter")) || way.isClosed() == false)
rules = lineRules;
else if ("polygon".equals(way.getTag("mkgmap:stylefilter")))
rules = polygonRules;
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] basic search
В сообщении от Понедельник 20 сентября 2010 22:37:53 автор Marko Mäkelä написал: > On Mon, Sep 20, 2010 at 10:24:55PM +0400, Maks Vasilev wrote: > >What way to create basic address and POI search in map created with > >mkgmap? > > > >OSM data have tag in addr:* shema > >(http://wiki.openstreetmap.org/wiki/Key:addr), map created with > >--make-poi- index and --index, but search in garmin not work. > > Which Garmin? The Edge 705, GPSMap 60CSx and possibly many older models > do not need either option. Garmin Oregon 300 > As far as I understand, the mkgmap --index option produces "half-cooked" > files that must be transferred by MapSource to the device. Once that is > done, the search should work. Others can hopefully chime in; I have > never used MapSource. I create gmapsupp.img with mkgmap and copy it to garmin. I never used MapSource too. -- wbr, Maks ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] STOP signs and routing
"Harri" ku...@bastu.net wrote on 20/09/2010 at 22:22:58 +1100
subject "[mkgmap-dev] STOP signs and routing" :
> On 09/20/2010 01:43 PM, maning sambale wrote:
>> A thread for improving routing gave this suggestion in the points style.
>>
>> highway=traffic_signals { add mkgmap:road-speed = '-2'; add
>> mkgmap:road-speed-min = '1' }
>> highway=crossing { add mkgmap:road-speed = '-1'; add
>> mkgmap:road-speed-min = '1' }
>> highway=stop { add mkgmap:road-speed = '-2'; add mkgmap:road-speed-min = '1'
>> }
>> traffic_calming=* { add mkgmap:road-speed = '-2'; add
>> mkgmap:road-speed-min = '1' }
>> barrier=toll_booth { add mkgmap:road-speed = '-2'; add
>> mkgmap:road-speed-min = '1' }
>>
>> The reduces the road speed of the way with the traffic_signal node.
>> I haven't tested fully but it seems to improve time calculation.
> I have tested it. There seems to be two major problems with that. First
> of all, it lowers the speed of the segment that has the poi. Lenght of
> that segment is sometimes just a few meters, sometimes a long road.
> So, it is more or less based on luck, whether the calculation of time is
> better or not. In any case, the time calculated should be longer.
> Matters could be improved by for example making an automatic split for a
> road if the segment containing speed-lowering poi gets too long.
This reduces the speed in both directions?
> Another problem is with Garmin routing. I'd be more interested in
> avoiding the low-speed points. However, Garmin does not use road speed
> too intelligently. Instead it seems to calculate the route based on
> road_class mostly.
Generally, the maxspeed value seems to be respected.
But I have seen a case where higher speed was applied to the road,
probably the speed of the next road segment.
Maybe it was triggered by some turn of the road.
You can see the effective road speed if you put your Garmin device in
"simulation" mode and route to some POI.
--
Sincerely
Hendrik Oesterlin - email hendrikmail2...@yahoo.de
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --transpatent not work
> But you could rightfully complain that mkgmap silently ignores unknown > command line switches. As far as I understand, the problem is that > there is no centralized command line parsing. Each code snippet looks > for its own magic parameter among all command line options. One thing > that could be done is to set a flag whenever an option gets processed. > Then, at the end of the run, mkgmap could list the ignored options. Have a look at the command line parsing stuff I added to the splitter, it makes it pretty easy to validate and document the params. Maybe a similar approach could be used in mkgmap? Chris ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] STOP signs and routing
On 09/20/2010 09:50 PM, Hendrik Oesterlin wrote: >> So, it is more or less based on luck, whether the calculation of time is >> better or not. In any case, the time calculated should be longer. >> Matters could be improved by for example making an automatic split for a >> road if the segment containing speed-lowering poi gets too long. > This reduces the speed in both directions? That is another problem with road speed reduction based on unidirectional poi. (unless you make some workaround such as generate overlaying one-way streets for a workaround or whatever). > You can see the effective road speed if you put your Garmin device in > "simulation" mode and route to some POI. Simulation yes. Routing, no. For example, routing for a faster roads ignores mostly minor roads and seems to caltulate faster route based on what was not ignored. So, a major road with lots of traffic_calming and traffic_signals gets preferred. :( -- harri ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] --transpatent not work
On 09/20/2010 07:35 PM, Marko Mäkelä wrote: > On Mon, Sep 20, 2010 at 10:15:58PM +0400, Maks Vasilev wrote: >> OMG! sorry :( > > But you could rightfully complain that mkgmap silently ignores unknown > command line switches. As far as I understand, the problem is that there I made a patch to check arguments a while back I'll dig it up and apply it. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1700: Fixes exception when there are no outer polygons.
Version 1700 was commited by steve on 2010-09-20 22:25:06 +0100 (Mon, 20 Sep 2010) Fixes exception when there are no outer polygons. -WanMil ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r1701: Modify DEM.java so that contours are always created in the same direction:
Version 1701 was commited by steve on 2010-09-20 23:07:21 +0100 (Mon, 20 Sep 2010) Modify DEM.java so that contours are always created in the same direction: http://koti.kapsi.fi/jpa/stuff/other/patch-contour-direction -- Petteri Aimonen ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
