[mkgmap-dev] Incorrect compilation of grid lines

Fri Jul 25 18:53:35 BST 2014

Hi Roger,

I prefer to solve the problem in mkgmap. My problem is that I don't yet
fully understand the math,
so I am not sure in what case the heron formula doesn't work. Up to now I've
only understood
that a term gets negative and therefore the calculation of the sqrt fails.
This results
in a distance of Double.NaN and I can detect that case. A simple patch seems
to fix
your problem, but I'd like to understand the effect first.
If I don't get that working, I'll implement the suppression flag as supposed
by Felix.

Gerd

Roger Calvert wrote
> Gerd,
> 
> Thanks for diagnosing this.
> 
> It would be possible for me to re-structure the file so that lines are 
> no longer than (say) 10km. This would increase the source (and 
> presumably .img)  file size somewhat, but should be handleable. I would 
> need to do the same for my latitude/longitude grid generator. (This 
> might also help with a rather different problem I have had with Osmand, 
> which does not always show labels on the lines within the screen area - 
> if the lines were much shorter, the labels would be more likely to 
> appear on screen.)
> 
> What maximum length of line would produce sensible results?
> 
> Of course, this would not solve the problem for other lines such as 
> contour lines, mentioned by Felix. Perhaps automatic detection of 
> excessively long lines, with some default action, combined with a 
> warning, would be appropriate. This would give the user the chance to 
> find and perhaps change the offending data.
> 
> Thanks again,
> 
> Roger
> 
> On 25/07/2014 09:46, Gerd Petermann wrote:
>> Hi Roger,
>>
>> the problem is caused by the routine that removes obsolete points from 
>> straigt lines.
>> This routine doesn't care (enough) about the spherical distortian.
>> The routine uses herons formula to "calculate distance of point in the 
>> middle to line c1,c2".
>> This formula is for 2D, but used to work good enough with the rather 
>> short ways
>> we have in OSM. (The formula is also used in the Douglas-Peucker filter).
>> With long lines the as in your data, the errors are too big and the 
>> routine returns garbage.
>>
>> If I got that right, we have to use the formula for the "Cross-track 
>> distance" as described here:
>> http://www.movable-type.co.uk/scripts/latlong.html
>>
>> Unfortunately, this routine uses more trigonometrical calculations, so 
>> it will be slower.
>>
>> @Programmers: Any other ideas?
>>
>> Gerd
>>
>> ------------------------------------------------------------------------
>> ------------------------------------------------------------------------
>>
>> _______________________________________________ mkgmap-dev mailing 
>> list 

> mkgmap-dev at .org

>  
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>> _______________________________________________
>> mkgmap-dev mailing list
>> 

> mkgmap-dev at .org

>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> -- 
> ------------------------------------------------------------------------
> 
> Roger Calvert
> http://www.rogercalvert.me.uk
> ------------------------------------------------------------------------
> 
> _______________________________________________
> mkgmap-dev mailing list

> mkgmap-dev at .org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
View this message in context: http://gis.19327.n5.nabble.com/Incorrect-compilation-of-grid-lines-tp5809502p5812733.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.