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?
