geoPositionSourceEnumId sounds good. making it a part of the PK is interesting, had not thought of that. I guess to fields for GPS elevation, then one that has the value and one the enumerates elevationUomId , like you say. you looking at 0.0 meters to 7K meters
Jacques Le Roux sent the following on 8/5/2008 2:36 PM: > 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? >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>> >>> >>> >>> >> >> >> > > > >
