[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