The part that is overlooked when wanting to go "simple" is that the coordinates that will be recorded become garbage data when they are stored without the correct coordinate system reference. Without the correct coordinate system reference, the possibility of "eventually" will be removed from your development path.
Building out the infrastructure to accomodate a coordinate system recreates about 90% of a GIS infrastructure. Someone with extensive knowledge of the nuts and bolts of the entity engine could look at the geotools module matrix plugins and get an idea on how to build that out appropriately in 1/10th of the effort. Taking that approach gives you standards compliance, all of the calculations you could be concerned with, and a internal map server to boot. David E Jones <[EMAIL PROTECTED]> wrote: I think I see where you're coming from Chris, and I'm for standards and existing toolsets. I think what we're talking about here is much more simple. Eventually we'll (hopefully!) get to the point where we want to define polygon boundaries for Geo records and that sort of thing, and doing so with Well Known Text (or even GML) might be a great way to go and would simplify the data model a lot. For now all we're looking for is a point location for an address, and possibly other things too. Actually, I kind of like the idea of having another ContactMechType for a terrestrial position, and maybe add some sort of positionContactMechId to the PostalAddress entity to point to it for an address. In any case, we want to keep this simple because chances are we will not use it with a GIS package, unless perhaps to pass the coordinates to something to determine if it is within a boundary or something. More likely we'll use really simple square or circle boundaries and such which are a lot easier to search within using any database using numerical coordinates, and those are easy since we're just talking about point coordinates. Of course, if someone wants to get into real GIS stuff and enhance the Geo and other entities in OFBiz for that... by all means please go for it! -David On Jul 2, 2008, at 4:42 PM, Chris Howe wrote: > David, > > I stand corrected on the significant digits used in TIGER. It seems > there is a slight difference in unit specificity in the projection > that I assumed versus what TIGER provides > > 4269 degree Unit = 0.01745329251994328 > Tiger degree Unit = 0.017453292519943295 > > This threw off the retrieval calculation of the coordinates and > didn't result in round numbers at the 6th decimal place and thus was > calculated to the maximum significant digits of the library (15 > digits). > > In regards to what I'm suggesting: I am simply suggesting that we > use the standards that have existed for over a decade for the > storage of geometrical data, namely Well-Known-Text or Well-Known- > Binary. The reason I am suggesting this is because you've already > submitted a desire to perform calculations that have been optimized > under libraries that use WTK/WTB. The other reason that I am > suggesting this is that latitude and longitude is not the only > coordinate system that would benefit from using the standard. For > instance, if someone has an RFID grid in their warehouse, they could > benefit from the same conventions being used. > > In regards to "What about the other databases?": I can't imagine > the other databases with spatial extensions would require approaches > that were much different to benefit from GIS. PostGIS happens to be > an implementation of the OGC standards, so databases that have an > implementation of that standard would benefit from code written to > that standard. > > The GeoTools Module Matrix plugins should give you an idea if you're > concerned about connecting to other databases. > > http://geotools.codehaus.org/Module+Matrix > > David E Jones wrote: > Here is what I found in a quick search: > > "Coordinates in the TIGER/Line® files are in decimal degrees and have > six > implied decimal places. The positional accuracy of these coordinates > is not > as great as the six decimal places suggest." > > That is from near the bottom of page 6 of this document: > > http://www.census.gov/geo/www/tiger/tigerua/ua2ktgr.pdf > > Or are you referring to a different TIGER? > > BTW Chris, I'm having a lot of trouble understanding your posts. I > don't know if others are running into the same thing, but much of the > time I'm not sure quite what you're getting at or what you propose as > many of these seem to be little snippets of thought instead of entire > thoughts... could explain a little more of what you have in mind? > > Also: I looked at the postgis stuff you added, and... what's the > point? If it only works with postgres how is that useful for OFBiz? > > -David > > > On Jul 2, 2008, at 4:31 AM, Chris Howe wrote: > >> In addition, TIGER road data is to 15 significant digits as is US >> data for county political boundaries. >> >> Chris Howe wrote: Roland wrote: Hi David, >> >> as I wasn't really sure about what to answer to your question, i >> looked a bit >> around: >> http://geocoder.us/blog/2006/03/23/how-many-digits-are-enough/ >> if their data is correct: 0.000001 degrees are 4.37184 inch or >> 11.1044736 >> centimeters >> that ought to be enough for everyone ;-) >> >> seriously: I think for applications like mapping out addresses that >> should be enough for years, but there may be other use cases i can't >> imagine right now. >> >> --Roland >> >> 640K ought to be enough for anybody. This reminds me of another >> benefit to WTK/WTB. WTK and WTB are not dependent on the coordinate >> system you are using. Whether your coordinate system is the >> latitudinal and longitudinal circles of the earth or whether they >> are the coordinate system of your RFID enabled warehosue, WTK and >> WTB handles them the same. Same data format, same use of >> projections, same reliability in application you build. Why record >> the same type of information in 15 different formats based on their >> use? >> > >
