And what about running on databases that don't have any GIS support?
-David
On Jul 1, 2008, at 2:11 PM, Chris Howe wrote:
I would greatly urge you to look into storing this information in
the Well Known Text or Well Known Binary formats instead. Most of
what will be useful in an ERP system will contain polygons with
hundreds (if not thousands) of verticies. Imagine the processing and
communication between the database and application that will occur
if you choose a system that separates the coordinate pairs. Many
databases have specialized functions added to their package to deal
with GIS data. Let us stand on the shoulders of giants on this one.
David E Jones <[EMAIL PROTECTED]> wrote:
Thanks for your comments Roland. I agree now that using a floating
point number is the best way to store them.
Right now we kind of "hack" floating point numbers for most databases,
ie we actually use a fixed-point number with only 6 decimal places.
I'm guessing for something like lat/long coordinates we'll want more
than 6 decimal places, so we might need to introduce a new field type
for this (which isn't difficult).
From your experience how many digits of precision within a degree is
needed for good lat/long coordinates?
-David
On Jun 28, 2008, at 2:53 PM, RolandH wrote:
Hi David,
just to comment on formating:
please save lat/long in degrees and use float or numeric types for
that, because with that you may do perimeter searches with db
support:
Having point P with lat/long and a radius, you can select all other
points from db which are within a square (center is P) supported by
indices of you're db. Afterwards you have only a limited set to
check against the radius again.
If you're database supports sin() / cos() you may take a look here
http://earthcode.com/blog/2006/11/hey_want_to_sort_your_query_by.html
and do everything with sql :)
Greetings,
Roland
David E Jones wrote:
The idea of having more generic lat/long coordinates is
interesting. For example, we could:
1. add lat/long fields to ContactMech
2. create a new ContactMechType for geo-spatial coordinates like
this, like "TerrestrialPosition" or something
3. add a new entity for TerrestrialPosition that is independent of
the ContactMech and Geo entities, and then related to with other
entities
We also need to discuss how to format these. They will probably
need to be string/text values so we can store these in any
database, so do we want the degrees/minutes/seconds/sub-seconds
format, or the degress/minutes/sub-minutes format, or the degrees/
sub-degrees format, or something else?
Also, I'm wondering if there is a good open source java library for
handling these, or even a standard object in the Java API (I'm not
aware of one, but haven't looked either). It would be nice to have
something to parse and normalize the strings and such, and of
course do calculations for distance or to see if a coordinate is
within a certain area, etc.
Jacques: for your needs now you might want to consider using extend-
entity if your timeline is tight. I'm guessing this needs more
discussion and research, etc before we get something good in place.
-David
On Jun 28, 2008, at 12:34 PM, Jacques Le Roux wrote:
Hi Rob,
I tested with some commercial addresses I will need to locate
(here in France) : results are not good enough... Morevover the
company I will do that for is already using (lat., long.). So I
will really need them. So my question to the community remains :
PostalAddress or extend-entity ?
Thanks
Jacques
Jacques
From: "Jacques Le Roux"
Thanks Rob,
This is an interesting information, I'm just discovering Google
Map API and related...
Jacques
From: "Rob Schapper"
Jacques,
Wouldn't it make more sense to use the google geocode methods to
get the lat/long from an address rather then store that info in
ofbiz?
Rob
On Jun 27, 2008, at 3:59 PM, Jacques Le Roux wrote:
Hi Chris,
It was a long time :o), thanks for comments
I need them to use with Google Map. To do something like
http://code.google.com/apis/maps/documentation/examples/marker-simple.html
you can see there map.setCenter(new GLatLng(37.4419,
-122.1419), 13);
Hopefully I will be able to do something general enough to be
reusable (should not be too hard, the tough part is already
done by
Google)
Jacques
From: "Chris Howe"
I wasn't going to comment on this because I don't think I have
the time available to see the discussion through to the end,
but
after reading David's "Data Model Changes Post", I'll toss my
two cents about this.
What are you wanting to ultimately do with Lat/Long? From my
experience with GeoServer earlier this year, storing Lat/Long
values
is rather inconvenient when doing computations and placing
points (and polygons) on Maps. It was much more convenient
to store
these points in the manner prescribed by postgis and using
the methods that are provided in those kinds of packages.
Also, as far
as data modeling, it's somewhat innacurate (although depending
on your application, possibly within acceptable bounds) to
refer to
an address as a point that has the specificity you'd be
assigning.
Jacques Le Roux wrote: Hi,
I will need to add Latitude and Longitude fields in
PostalAdress. Could this be a change commited ?
I will also need to add a type PHONE_HOTLINE in
ContactMechPurposeType.
Else, of course I will use
Thanks
Jacques
