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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>> >> >
