[Patch v2] higher precision in coordinates

Hi, attached is v2 of the patch. It still only solves problems related to routing, but I see many possible improvemets with more coding. I think we should create a branch for it, but I first like to finish work on the reduce_limits branch, which in turn is more useful in combination with the mergeroads branch. Gerd

Hi Gerd, looks great! I didn't test it carefully but it seems to be safe to be commited. I think I will start now with changing how to assign the label fields of POIs and streets in the mergeroads branch. After finishing that the branch should be ready for merging it to trunk (ok, some documentation stuff need to be done... :-) WanMil
Hi,
attached is v2 of the patch. It still only solves problems related to routing, but I see many possible improvemets with more coding. I think we should create a branch for it, but I first like to finish work on the reduce_limits branch, which in turn is more useful in combination with the mergeroads branch.
Gerd

Hi WanMil,
I think I will start now with changing how to assign the label fields of POIs and streets in the mergeroads branch. After finishing that the branch should be ready for merging it to trunk (ok, some documentation stuff need to be done... :-)
sounds good. Some days ago you mentioned routing problems in the branch. Is that problem solved? Gerd

Hi WanMil,
I think I will start now with changing how to assign the label fields of POIs and streets in the mergeroads branch. After finishing that the branch should be ready for merging it to trunk (ok, some documentation stuff need to be done... :-)
sounds good. Some days ago you mentioned routing problems in the branch. Is that problem solved?
I'll have to check that again. There was a problem when I tried to compile a car only map. So all access flags were set to false except the car flag. In this case all in roundabouts I always go the routing instruction "leave on 1st exit". No matter if it was the 1st, 2nd or another exit. Maybe it has something to do with a "irregular" combination of the access field. I will try to reproduce...
Gerd

Hi WanMil,
I think I will start now with changing how to assign the label
fields of
POIs and streets in the mergeroads branch. After finishing that the branch should be ready for merging it to trunk (ok, some documentation stuff need to be done... :-)
sounds good. Some days ago you mentioned routing problems in the branch. Is that problem solved?
I'll have to check that again. There was a problem when I tried to compile a car only map. So all access flags were set to false except the car flag. In this case all in roundabouts I always go the routing instruction "leave on 1st exit". No matter if it was the 1st, 2nd or another exit. Maybe it has something to do with a "irregular" combination of the access field.
I will try to reproduce...
Hi Gerd, I couldn't reproduce the problem. I think it might have something to do if all access flags and the special flags like throughroute, carpool etc. are all set to 'no' (which means the bit is 1). Testing two different styles I could not find such a problem any more so I think it is not relevant for the moment. Maybe we can test later on some some special cases which does not make sense in real life. WanMil

Hi WanMil, WanMil wrote
looks great! I didn't test it carefully but it seems to be safe to be commited.
I started a new branch called high-prec-coord. So far I tried to use the higher precision also in the routines that use java.awt.geom.Area. Unfortunately, this gives drastically higher run times (e.g. in the PrecompSeaGenerator), and I saw no improvements, but new errros (e.g. islands written as sea and as land). I assume the higher CPU time is caused by the fact that the internal data structures are able to simplify the rounded coordinates (they probably remove spikes and points on straight lines), with the higher precision this is less likely, and therefore all routines like intersects() or contains() have to check more points. I still hope to be able to use the higher precision to remove some artifacts like ugly roundabouts... Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Patch-v2-higher-precision-in-coordinates-tp57... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (3)
-
Gerd Petermann
-
GerdP
-
WanMil