[OSM-dev] Osmosis Replication Statistics

Brett Henderson brett at bretth.com
Sat Sep 1 01:33:54 BST 2007

Robert (Jamie) Munro wrote:
> IMHO it /is/ ideal. Using floats for lat/lon is stupid - it just
> means that you are more accurate at measuring places nearer the equator
> and nearer the Greenwich meridian, and less accurate as you move further
> away. Use 2^N/360 as your fixed constant, where N is the number of bits
> you use in your integer. 32 bits gives a precision down to less than a
> cm. If you are working in a sufficiently low level language, you can
> ignore overflows and signed/unsigned issues because they cancel each
> other out, and crossing the date line works by magic.
Okay, thanks for the info.  For the purposes of this filter it sounds 
like 32-bit integers are more than accurate enough for the job.  It will 
probably come down to how quick some of these "area.contains" 
implementations are.  Other advantages of integer precision such as the 
date line wrapping described above don't sound applicable to my filter 
but presumably would come into play if OSM as a whole adopted an integer 
coordinate system.

For what it's worth, the java.awt.geom.Path2D.Double class sounds like 
what I was looking for (it is similar to GeneralPath but using double 
precision) but it is only available in JDK 1.6 which is greater than my 
current minimum of JDK1.5.

More information about the dev mailing list