From: "David E Jones" <[EMAIL PROTECTED]>
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.
Yes and this is even simpler. I followed the PartyContactMech pattern because I thought it was a best practise. But obviously like
that the scope will be wider.
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.
Yes, I remember this discussion. I will add it
Thanks
Jacques
-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?
