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. As a side note: just for future would like a elevation field. this is for GPS.
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? >>>>>> >>>>> >>>>> >>>> >>>> >> > > > >
