From: "BJ Freeman" <[EMAIL PROTECTED]>
I like the idea of the TerrestrialPosition entity.
Maybe have field for the source of the lon/lat.
like google, yahoo, USPS as enumerated types.
I say this because i find a difference in the lon/lat for each source.
and there may be a need to have a different TerrestrialPosition for
each one to make that particular system work correctly. Maybe a parent
child relationship, to save pointing other entities.
This is a bit frightening but unfortunately not really surprising. I did not
check, so I rely upon you on this.
I don't think we need more than a field geoPositionSourceEnumId using a relation to Enumeration with a table for this information
except if someone has a better idea/information.
So each source variations will be available, geoPositionSourceEnumId being part
of the primary key (with TerrestrialPositionId).
As a side note: just for future would like a elevation field.
this is for GPS.
OK, I will add which unit would you prefer ? Maybe better using an
elevationUomId referring to a LENGTH_MEASURE ?
Thanks
Jacques
David E Jones sent the following on 8/5/2008 8:41 AM:
It might be better to have an independent ID for the TerrestrialPosition
(like terrestrialPositionId) and have things point to it rather than
having it point to other things. In other words we would add a
terrestrialPositionId to the ContactMech instead of putting a
contactMechId on TerrestrialPosition. In that way anything could point
to it.
Also, considering the discussions from before maybe we should add a text
field for Well Known Text that can be used as an alternative to (or
perhaps supplement to) the simple lat/lon.
-David
On Aug 4, 2008, at 3:51 PM, Jacques Le Roux wrote:
I resurrect this thread to let you know that I'm ready to work on this
I'd like to create, as we agreed but please confirm,
. a new entity TerrestrialPosition with at least these fields for now
. contactMechId
. latitude (using new type degree being NUMERIC(18,6))
. longitude (using new type degree being NUMERIC(18,6))
. comment using type comment
. add of a new ContactMechType : TerrestrialPosition
The same mechanism used to relate PostalAddress to a Party, a Facilty,
an Invoice, an Order or an OrderItem (so far) will be used to relate a
TerrestrialPosition (through PartyContactMech, FaciltyContactMech, etc. )
If needed we can put more decimals in degree, but RolandH pointed out
that 6 decimals is enough for 4.37184 inch or 11.1044736 centimeters !!!
If nobody disagree I will go for that (as soon as Adam will have fixed
OFBiz ;o)
Jacques
From: "Jacques Le Roux" <[EMAIL PROTECTED]>
From: "David E Jones" <[EMAIL PROTECTED]>
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.
From http://en.wikipedia.org/wiki/Well-known_text this sounds like a
good idea to me.
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.
I undestand and agree with Chris's argument, but it's true that I
don't need such sophistication for the moment.
Using the extensibility pattern sounds a 1st raisonnable approach to
me. Obviously better than introducing lat+long in PostalAddress and
let future open ...
Jacques
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 <[EMAIL PROTECTED]> 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?
