Re: [mkgmap-dev] max-speed and arbitrary values

2009-06-04 Thread Wolfgang v. Hansen

On Thu, 4 Jun 2009, Carlos Dávila wrote:


Marco Certelli escribió:

I think I can confirm what said here. My nuvi 255 seems to learn the speed I 
drive on each road (with impact on routing decision next time I drive the same 
area).


I think nuvi 300 doesn't have this behaviour. I have driven many times
my road to work and it continues calculating about twice the time it
really takes me from home to work (about 50 km trip). Using city
navigator for the same route, time calculation is correct.


That is really strange. What's your firmware version?


-Wolfgang
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


[mkgmap-dev] Commit: r1060: Enhance --replace-short-arcs to take an optional minimum arc length.

2009-06-04 Thread svn commit
Version 1060 was commited by markb on 2009-06-04 21:50:20 +0100 (Thu, 04 Jun 
2009) 

Enhance --replace-short-arcs to take an optional minimum arc length.

As before, specifying --replace-short-arcs will replace zero length
arcs but if you specify a minimum length, e.g. --replace-short-arcs=3.5
then all arcs shorter than that distance will be removed.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Commit: r1059: New approach to the too many nodes in region problem - carry on regardless.

2009-06-04 Thread Mark Burton

Hi Clinton,

> On Wed, Jun 3, 2009 at 5:41 PM, Mark Burton  wrote:
> >
> > Let's see how this does - I have tried it out on 63660006.osm and the
> > resulting map loads into mapsource OK and is generally fine.
> 
> I have also tested this, and it worked fine (with the exception of the
> broken routing in the damaged area, but that is to be expected).
> 
> Thanks very much for this fix!

Well, as we know, it's a hack but if it allows the map to build and be
mostly usable, it's a worthwhile hack.
 
> I also apologise, because I thought that r1054 introduced the
> "croaking" feature. But if I now understand it correctly, the commit
> simply made the croaking more elegant. Previously mkgmap would "spew"
> error messages and then croak.

No need to apologise, I understood your unhappiness with how it was.
But yes, it would have bombed anyway, I just made it a little more
useful by reporting the bbox and then exiting without spewing out more
garbage.

Cheers,

Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length

2009-06-04 Thread Mark Burton

Hi Felix,

> Shame on me, I had in my batch the call for the unpatched mkgmap 
> version, which of course did not.

OK.
 
> What can I say about the patch? Get it into TRUNK

I will commit it soon as it won't affect the default operation.
 
> Finally Routing over longer distances IS possible. Route calculation 
> time decreased in mapsource by up to 50%, and possible route length 
> increased about 20-25%.
> Also no single Mapsource Crash since!

Good.
 
> At least in Austria where because of the import, many roads are not 
> connected, this patch is absolutely essential!

The patch only merges nodes that are close and already connected.
It doesn't merge nodes that are close and not connected.
 
> On my Vista HCx also many destinations that previously took 2-3 minutes 
> to calculate just calculated only 20-30 seconds!

Great.

> Maybe don't enable it by default, I have not really tested whether now 
> there are any problems with roads connected that should not be 
> connected, but so far it has been working great!

I will commit something that has the same effect as the patch you have
tried.

Cheers,

Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length

2009-06-04 Thread Felix Hartmann




Shame on me, I had in my batch the call for the unpatched mkgmap
version, which of course did not.

What can I say about the patch? Get it into TRUNK

Finally Routing over longer distances IS possible. Route calculation
time decreased in mapsource by up to 50%, and possible route length
increased about 20-25%. 
Also no single Mapsource Crash since!

At least in Austria where because of the import, many roads are not
connected, this patch is absolutely essential!

On my Vista HCx also many destinations that previously took 2-3 minutes
to calculate just calculated only 20-30 seconds!
Maybe don't enable it by default, I have not really tested whether now
there are any problems with roads connected that should not be
connected, but so far it has been working great!

Mark Burton wrote:

  Hi Felix,

  
  
Did this work for you on the example road?

  
  
Yes, the small way gets zapped:

2009/06/04 13:08:43 INFO (Osm5XmlHandler):   Way Thomas-Tamussino-Straße (OSM id 27174349) has short arc (2.87m) - removing it by merging node 371185471 into 286059582

  
  
I tried it and it would not work for me. Road is still broken.

I notice that on 0 I have the same filesizes as before - so nothing is 
broken. Increasing from 0- 6m filesize gets bigger, but nevertheless the 
street is missing 3m, attached a screenshot from gpsmapedit (don't mind 
the shopping symbol, that is 0x2f0f which I use for road-name-pois). 
Actually whether I specify 3 or 6 does not matter for austria.osm.bz2, 
filesize stays identiacal.

  
  
I attach a screenshot of what I get with gpsmapedit.

Cheers,

Mark
  
  
  
  
  

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] max-speed and arbitrary values

2009-06-04 Thread Carlos Dávila
Marco Certelli escribió:
> I think I can confirm what said here. My nuvi 255 seems to learn the speed I 
> drive on each road (with impact on routing decision next time I drive the 
> same area).
>   
I think nuvi 300 doesn't have this behaviour. I have driven many times
my road to work and it continues calculating about twice the time it
really takes me from home to work (about 50 km trip). Using city
navigator for the same route, time calculation is correct.
Regards
Carlos
> Also I confirm that many roads has a max speed info that is shown on the 
> screen while I drive the road.
>
> --- Gio 4/6/09, Wolfgang v. Hansen  ha scritto:
>
>   
>> Da: Wolfgang v. Hansen 
>> Oggetto: Re: [mkgmap-dev] max-speed and arbitrary values
>> A: "Development list for mkgmap" 
>> Data: Giovedì 4 giugno 2009, 16:24
>> On Wed, 3 Jun 2009, Thilo Hannemann
>> wrote:
>>
>> 
>>> Somebody mentioned also that the GPS units will
>>>   
>> "learn" the speed you are actually driving and use that for
>> their calculation. If this is speculation or based on facts
>> I don't know. At least with my Oregon 300 I doubt it: As I
>> use it all the time with my maps I'm cycling always in the
>> car mode. So far the ETAs are still very wrong. If the GPS
>> would learn the speed they should become more realistic over
>> time.
>>
>> At least the car navs (StreetPilot, nüvi) do learn your
>> speed profile -- don't know about the outdoor navs though.
>> These are probably the same set of speeds that you can set
>> in MapSource.
>>
>> In addition, there should also be a slot for the max. speed
>> for each road in the maps. Newer devices (I don't have one
>> of them though) along with current maps tell you when you
>> are driving too fast. This is a feature that had been
>> introduced by Garmin/Navteq quite recently.
>>
>>
>> -Wolfgang
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>> 
>
>
>   
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>   


-- 
Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, 
.ppt, .pptx, .mdb, mdbx

Instale OpenOffice desde http://es.openoffice.org/programa/index.html
OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. 
Gratis y totalmente legal.
OpenOffice funciona mejor que otros paquetes de oficina.
OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas 
versiones.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length

2009-06-04 Thread Mark Burton

Hi Felix,

> Did this work for you on the example road?

Yes, the small way gets zapped:

2009/06/04 13:08:43 INFO (Osm5XmlHandler):   Way Thomas-Tamussino-Straße (OSM 
id 27174349) has short arc (2.87m) - removing it by merging node 371185471 into 
286059582

> I tried it and it would not work for me. Road is still broken.
> 
> I notice that on 0 I have the same filesizes as before - so nothing is 
> broken. Increasing from 0- 6m filesize gets bigger, but nevertheless the 
> street is missing 3m, attached a screenshot from gpsmapedit (don't mind 
> the shopping symbol, that is 0x2f0f which I use for road-name-pois). 
> Actually whether I specify 3 or 6 does not matter for austria.osm.bz2, 
> filesize stays identiacal.

I attach a screenshot of what I get with gpsmapedit.

Cheers,

Mark
<>___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit: r1059: New approach to the too many nodes in region problem - carry on regardless.

2009-06-04 Thread Clinton Gladstone
On Wed, Jun 3, 2009 at 5:41 PM, Mark Burton  wrote:
>
> Let's see how this does - I have tried it out on 63660006.osm and the
> resulting map loads into mapsource OK and is generally fine.

I have also tested this, and it worked fine (with the exception of the
broken routing in the damaged area, but that is to be expected).

Thanks very much for this fix!

I also apologise, because I thought that r1054 introduced the
"croaking" feature. But if I now understand it correctly, the commit
simply made the croaking more elegant. Previously mkgmap would "spew"
error messages and then croak.

Cheers.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] max-speed and arbitrary values

2009-06-04 Thread Marco Certelli

I think I can confirm what said here. My nuvi 255 seems to learn the speed I 
drive on each road (with impact on routing decision next time I drive the same 
area).

Also I confirm that many roads has a max speed info that is shown on the screen 
while I drive the road.

--- Gio 4/6/09, Wolfgang v. Hansen  ha scritto:

> Da: Wolfgang v. Hansen 
> Oggetto: Re: [mkgmap-dev] max-speed and arbitrary values
> A: "Development list for mkgmap" 
> Data: Giovedì 4 giugno 2009, 16:24
> On Wed, 3 Jun 2009, Thilo Hannemann
> wrote:
> 
> > Somebody mentioned also that the GPS units will
> "learn" the speed you are actually driving and use that for
> their calculation. If this is speculation or based on facts
> I don't know. At least with my Oregon 300 I doubt it: As I
> use it all the time with my maps I'm cycling always in the
> car mode. So far the ETAs are still very wrong. If the GPS
> would learn the speed they should become more realistic over
> time.
> 
> At least the car navs (StreetPilot, nüvi) do learn your
> speed profile -- don't know about the outdoor navs though.
> These are probably the same set of speeds that you can set
> in MapSource.
> 
> In addition, there should also be a slot for the max. speed
> for each road in the maps. Newer devices (I don't have one
> of them though) along with current maps tell you when you
> are driving too fast. This is a feature that had been
> introduced by Garmin/Navteq quite recently.
> 
> 
> -Wolfgang
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] max-speed and arbitrary values

2009-06-04 Thread Wolfgang v. Hansen

On Wed, 3 Jun 2009, Thilo Hannemann wrote:

Somebody mentioned also that the GPS units will "learn" the speed you 
are actually driving and use that for their calculation. If this is 
speculation or based on facts I don't know. At least with my Oregon 300 
I doubt it: As I use it all the time with my maps I'm cycling always in 
the car mode. So far the ETAs are still very wrong. If the GPS would 
learn the speed they should become more realistic over time.


At least the car navs (StreetPilot, nüvi) do learn your speed profile -- 
don't know about the outdoor navs though. These are probably the same set 
of speeds that you can set in MapSource.


In addition, there should also be a slot for the max. speed for each road 
in the maps. Newer devices (I don't have one of them though) along with 
current maps tell you when you are driving too fast. This is a feature 
that had been introduced by Garmin/Navteq quite recently.



-Wolfgang
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length

2009-06-04 Thread Felix Hartmann

Did this work for you on the example road?
I tried it and it would not work for me. Road is still broken.

I notice that on 0 I have the same filesizes as before - so nothing is 
broken. Increasing from 0- 6m filesize gets bigger, but nevertheless the 
street is missing 3m, attached a screenshot from gpsmapedit (don't mind 
the shopping symbol, that is 0x2f0f which I use for road-name-pois). 
Actually whether I specify 3 or 6 does not matter for austria.osm.bz2, 
filesize stays identiacal.


Felix

Mark Burton wrote:

As promised, here's a patch that will let you specify a min arc length
like this --replace-short-arcs=3.5. If you don't specify a length, it
will only remove zero-length arcs (as it does now).

Cheers,

Mark
  



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
<>___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] [PATCH v1] - extend --replace-short-arcs option to take min arc length

2009-06-04 Thread Mark Burton

As promised, here's a patch that will let you specify a min arc length
like this --replace-short-arcs=3.5. If you don't specify a length, it
will only remove zero-length arcs (as it does now).

Cheers,

Mark
diff --git a/resources/help/en/options b/resources/help/en/options
index 6358704..ca9f115 100644
--- a/resources/help/en/options
+++ b/resources/help/en/options
@@ -136,8 +136,11 @@ Misc options:
 	in which they appear in the OSM input. Without this option,
 	the order in which the elements are processed is not defined.
 
---remove-short-arcs
-	Merge nodes to remove short arcs that can cause routing problems.
+--remove-short-arcs[=MinDistance]
+	Merge nodes to remove short arcs that can cause routing
+	problems. If MinDistance is specified (in metres), arcs
+	shorter than that length will be removed. If a distance is not
+	specified, only zero-length arcs will be removed.
 
 --road-name-pois[=GarminCode]
 	Generate a POI for each named road. By default, the POIs'
diff --git a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
index 22794e2..4971b22 100644
--- a/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
+++ b/src/uk/me/parabola/mkgmap/reader/osm/xml/Osm5XmlHandler.java
@@ -89,14 +89,18 @@ class Osm5XmlHandler extends DefaultHandler {
 	private final boolean ignoreBounds;
 	private final boolean ignoreTurnRestrictions;
 	private final boolean routing;
-	private final boolean removeShortArcs;
+	private final Double minArcLength;
 	private final String frigRoundabouts;
 
 	public Osm5XmlHandler(EnhancedProperties props) {
 		makeOppositeCycleways = props.getProperty("make-opposite-cycleways", false);
 		ignoreBounds = props.getProperty("ignore-osm-bounds", false);
 		routing = props.containsKey("route");
-		removeShortArcs = props.getProperty("remove-short-arcs", false);
+		String rsa = props.getProperty("remove-short-arcs", null);
+		if(rsa != null)
+			minArcLength = (rsa.length() > 0)? Double.parseDouble(rsa) : 0.0;
+		else
+			minArcLength = null;
 		frigRoundabouts = props.getProperty("frig-roundabouts");
 		ignoreTurnRestrictions = props.getProperty("ignore-turn-restrictions", false);
 		if (props.getProperty("preserve-element-order", false)) {
@@ -402,7 +406,7 @@ class Osm5XmlHandler extends DefaultHandler {
 
 		nodeMap = null;
 
-		if(removeShortArcs)
+		if(minArcLength != null)
 			removeShortArcsByMergingNodes();
 
 		nodeIdMap = null;
@@ -520,9 +524,17 @@ class Osm5XmlHandler extends DefaultHandler {
 		if(arcCount != null) {
 			// merge this node to previous node if the
 			// two points have identical coordinates
-			// but they are not the same point object
-			if(p != previousNode && p.equals(previousNode)) {
-log.info("  Way " + way.getTag("name") + " (OSM id " + way.getId() + ") has zero length arc - removing it by merging node " + nodeIdMap.get(p) + " into " + nodeIdMap.get(previousNode));
+			// or are closer than the minimum distance
+			// allowed but they are not the same point
+			// object
+			if(p != previousNode &&
+			   (p.equals(previousNode) ||
+(minArcLength != null &&
+ p.distance(previousNode) < minArcLength))) {
+if(p.equals(previousNode))
+	log.info("  Way " + way.getTag("name") + " (OSM id " + way.getId() + ") has zero length arc - removing it by merging node " + nodeIdMap.get(p) + " into " + nodeIdMap.get(previousNode));
+else
+	log.info("  Way " + way.getTag("name") + " (OSM id " + way.getId() + ") has short arc (" + ((int)(100 * p.distance(previousNode)))/100.0 + "m) - removing it by merging node " + nodeIdMap.get(p) + " into " + nodeIdMap.get(previousNode));
 ++numNodesMerged;
 replacements.put(p, previousNode);
 // add this node's arc count to the node
@@ -625,7 +637,7 @@ class Osm5XmlHandler extends DefaultHandler {
 		//co.incCount();
 		if (co != null) {
 			currentWay.addPoint(co);
-			if(removeShortArcs)
+			if(minArcLength != null)
 nodeIdMap.put(co, id);
 		}
 	}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem routing over very short roads

2009-06-04 Thread Felix Hartmann


Mark Burton wrote:

Hi Felix,

  

Do you see any solution to this problem?



Sorry, I don't have a plan at this time.

  
I think if a way is shorter than 3.4m we get the problem. I don't think 
it is because of the duplicate ways.



It's more subtle than that because I could make a small map (just a few
100ms height and width) that included that way and mapsource was quite
happy with it but when I processed your big file, it didn't like it - so
either the problem is related to the density of stuff around or the
size of the area being processed or something...

  
Could we maybe have a filter that joins such tiny roads to the ones it 
is connected too?



Well, if it becomes zero length that will happen anyway because that's
what the new remove-short-arcs option does. What I could do is extend
that code to allow the min distance to be specified so you could say
--remove-short-arcs=3.5 and it would zap all arcs under than length but
without the distance, i.e. just --remove-short-arcs would only zap zero
length arcs. I will produce a patch to do that, should be quick to do.
  
Would that connect all notes that are closer than 3.5m together, or only 
nodes that are connected to each other?
My thinking is that if in case a road crosses another on a bridge, and 
now on the top road a node lies within 3.5m of the distance of the road 
below the brige, and then they are joined, this patch would only be good 
for experimenting, but not for really usable maps. If it only deletes 
nodes that are connected anyhow than I think maps will be quite usable.


I suspect the same error to be actually taking place quite often (about 
say every 10. route calculation of aerial distance 30-40km ). Though I 
would have to closely watch autorouting routes more often.


Felix

Cheers,

Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

  
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem routing over very short roads

2009-06-04 Thread Mark Burton

Hi Felix,

> Do you see any solution to this problem?

Sorry, I don't have a plan at this time.

> I think if a way is shorter than 3.4m we get the problem. I don't think 
> it is because of the duplicate ways.

It's more subtle than that because I could make a small map (just a few
100ms height and width) that included that way and mapsource was quite
happy with it but when I processed your big file, it didn't like it - so
either the problem is related to the density of stuff around or the
size of the area being processed or something...

> Could we maybe have a filter that joins such tiny roads to the ones it 
> is connected too?

Well, if it becomes zero length that will happen anyway because that's
what the new remove-short-arcs option does. What I could do is extend
that code to allow the min distance to be specified so you could say
--remove-short-arcs=3.5 and it would zap all arcs under than length but
without the distance, i.e. just --remove-short-arcs would only zap zero
length arcs. I will produce a patch to do that, should be quick to do.

Cheers,

Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Problem routing over very short roads

2009-06-04 Thread Felix Hartmann

Do you see any solution to this problem?
I think if a way is shorter than 3.4m we get the problem. I don't think 
it is because of the duplicate ways.


Could we maybe have a filter that joins such tiny roads to the ones it 
is connected too?

Felix

Mark Burton wrote:

Hi Felix,

  
I have just uploaded my source data, try your calculation on it, I think 
it will fail too for you as well.


http://openmtbmap.x-nation.de/maps/Debug/63660008.osm.gz



That's more like it. With that map, the little segment at the N of the
bridge weirds out. If you check the diagnostic output, you will see
that mkgmap is not deleting that way so the end points have not
resolved to the same coordinates (to make it zero length) but maybe
mapsource doesn't like ways that short and is barfing on it.

Cheers,

Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

  
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem routing over very short roads

2009-06-04 Thread gypakk
> okay, that might be the problem. In potlatch I could not discover this.

It's a common mistake. I had some problems myself with these multiple copies of 
ways. This could help:

http://wiki.openstreetmap.org/wiki/Stammtisch_Hannover_Tipps#Doppelte_Wege_finden
 (German)

http://wiki.openstreetmap.org/wiki/Potlatch/Keyboard_shortcuts (English, look 
for '/' key description)

Markus

> I did touch the node however already, deleting and and re-adding it to 
> make sure it's connected, maybe It's now longer than 3.4m. It was just 
> around 3m before.
> I have just uploaded my source data, try your calculation on it, I think 
> it will fail too for you as well.
> 
> http://openmtbmap.x-nation.de/maps/Debug/63660008.osm.gz
> 
> Mark Burton wrote:
> > Just discovered a weirdness in that map.
> >
> > The short segment at the northern end of the bridge is actually two
> > ways (one on top of the other). Using the middle mouse button in josm
> > you can see that. Perhaps, this is the cause of your problems.
> >
> > Cheers,
> >
> > Mark
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> >   
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Problem routing over very short roads

2009-06-04 Thread Mark Burton

Hi Felix,

> I have just uploaded my source data, try your calculation on it, I think 
> it will fail too for you as well.
> 
> http://openmtbmap.x-nation.de/maps/Debug/63660008.osm.gz

That's more like it. With that map, the little segment at the N of the
bridge weirds out. If you check the diagnostic output, you will see
that mkgmap is not deleting that way so the end points have not
resolved to the same coordinates (to make it zero length) but maybe
mapsource doesn't like ways that short and is barfing on it.

Cheers,

Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Problem routing over very short roads

2009-06-04 Thread Felix Hartmann

okay, that might be the problem. In potlatch I could not discover this.
I did touch the node however already, deleting and and re-adding it to 
make sure it's connected, maybe It's now longer than 3.4m. It was just 
around 3m before.
I have just uploaded my source data, try your calculation on it, I think 
it will fail too for you as well.


http://openmtbmap.x-nation.de/maps/Debug/63660008.osm.gz

Mark Burton wrote:

Just discovered a weirdness in that map.

The short segment at the northern end of the bridge is actually two
ways (one on top of the other). Using the middle mouse button in josm
you can see that. Perhaps, this is the cause of your problems.

Cheers,

Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

  

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Problem routing over very short roads

2009-06-04 Thread Mark Burton

Just discovered a weirdness in that map.

The short segment at the northern end of the bridge is actually two
ways (one on top of the other). Using the middle mouse button in josm
you can see that. Perhaps, this is the cause of your problems.

Cheers,

Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


[mkgmap-dev] Re: Again Picture of broken road, in case it got blocked by mailing list too

2009-06-04 Thread Mark Burton

I downloaded again, made a map and this is what it looks like in
mapsource. I can't explain why your image is broken.

Cheers,

Mark

<>___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Problem routing over very short roads

2009-06-04 Thread Felix Hartmann




1. See here:
http://www.openstreetmap.org/edit?lat=48.084294&lon=16.296498&zoom=18

Have a look at the street running paralell to the railwaylines (name
Thomas-Tamussino-Straße, ref B11).
Mappers have nicely and correctly entered the bridge. The section after
the bridge is only about 3m long, because after the next intersection
the street name changes.

On compiling, these 3m get dropped and are missing. What's even worse,
because the section is so short, Any autorouting wanting to go over
that place, crashes in Mapsource (at least it does not crash Mapsource
however, only route calculation stops with error). 
Here is a small screenshot of how it looks like on 20m zoom in
Mapsource:


I'm more than sure that there are several other places were we face the
same problem, which at first look seem like mappers made mistake and
did not connect road, but in reality it's one of those road segments
shorter than 3.4m getting dropped.






___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev