if I may. think of it this way an address is fixed, never moves and geopoint is the same now if the contact mech point to the address the the address will give the geopoint so you have a mechanism to find the geopoint, if just the address point to the geo point, in a view.
so contact mech points to the address from the address you find the geopoint Jacques Le Roux sent the following on 8/7/2008 2:12 PM: > From: "David E Jones" <[EMAIL PROTECTED]> >> >> On Aug 5, 2008, at 4:08 PM, Jacques Le Roux wrote: >> >>> From: "David E Jones" <[EMAIL PROTECTED]> >>>> >>>> On Aug 5, 2008, at 2:37 PM, Jacques Le Roux wrote: >>>> >>>>> 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. >>>> >>>> This is something we should maybe discuss more, ie whether the >>>> TerrestrialPosition should be a type of ContactMech or it's own >>>> independent thing. I was thinking the independence might be >>>> better, and we would have more control over what it is attached >>>> to. >>>> In other words, the use patterns and relationships to other >>>> entities are a little different than what is done with >>>> ContactMechs. >>>> >>>> Still, if anyone thinks otherwise... please share. >>> >>> Actually what I said above is not true. The scope will not be wider. >>> You can get the same using the ContactMech pattern. It's >>> only a bit harder since you have to create a specific entity (like >>> FacilityLocationContactMech) and make the association >>> between the 2 other entities each time you want to relate a new >>> entity (like say FacilityLocation). In the second case only one >>> association to TerrestrialPosition would be needed. So it's up to >>> you guys, sometimes breaking the rules is good, sometimes >>> it's not, we have to really think about it ... before... >> >> What do you mean by "break the rules"? I don't see any rules being >> broken here... > > Yes actually, I was just thinking about the EntityNameContactMech > pattern, not a rule indeed. > And because I wondered why we'd use this pattern in most other cases and > not for GPS Geolocation, I just reviewed how Len Silverston > suggests to deal with contact informations. > At this stage I must admit that things were not much more clear. As far > as I read Len speaks only about PartyContactMech and > FacilityContactMech, but it's easy to extrapolate more usages as it's > done in OFBiz. > > Now, please let me think loud. What is the difference between a postal > address and a GPS point ? Is there more differences between > them than between, say a telecom number and a postal address ? > Obviously telecom numbers and a postal addresses have something in > common that a GPS point does not share: they are mechanismes to > contact somebody (or something at large). A GPS point is only a mean to > locate somebody (or something at large), you can't contact a > GPS point. So yes, it makes sense to differntiate a GPS point from other > contact mech. A GPS point is not a contact mech as Len > Silverstion defines one. It's a mean to locate not to contact. So now I > better understant why you wanted things to point to it > rather than having it point to other things. I still wonder though if we > should not think a bit more about it. Putting a > terrestrialPositionId in ContactMech does not make sense, as it's not a > mean to contact but locate. Should we not introduce > something else. Like a LocateMech, which could be maybe used for other > stuff in future ? > > Let me dream now (you are allowed to no read that :o) : I live in the > country (not so far from town, but country). And where I live > there is no numbers to the road. So it's hard to find me (I did not make > it purposely ;o). Sometimes it's cool, sometimes it's very > annoying. Like when you receive a CD from Amazon the 1st time (and even > after : deliverymen change). Sometimes it's even worse : the > French postal service, "La Poste", will change its status soon and will > become a private company (yes things are changing, even in > France). The bad side (there is always one in all things) is that they > speak to not delilver anymore addresses without numbers. You > see ? If we were using geolocation (with a comment for more) in place of > addresses I will not have this problems. We are still using > old tools whereas we have already what is needed to do more. > >> As with anything you design to requirements, and try to make things >> flexible but many-to-many relationships are not inherently >> better in any way than many-to-one relationships, they are just >> different and better for use in different situations. > > Yes I agree, I did not have thought enough about that. What do you think > about the LocateMech idea ? Apart its name, would it be > really useful in future or shall we stay with ContactMech only? > > One thing to note after this : an address may be used to contact but > also only to locate (like for delivery). Same with a cell > phone, when the police investigates... So maybe a ContacMech is enough, > in OFBiz at least... > > Sorry for the long post, but you asked for thinking, I tried and finally > find your 1st solution simple and clear : > 1. add lat/long fields to ContactMech > 2. create a new ContactMechType for geo-spatial coordinates like this, > like "TerrestrialPosition" or something > 3. add a new entity for TerrestrialPosition that is independent of the > ContactMech and Geo entities, and then related to with other entities$ > > BTW, what do yout think about my answer to BJ about different > geolocation sources (yahoo, google, etc.) : a primary key field > geoPositionSourceEnumId using a relation to Enumeration in > TerrestrialPosition entity? > And his proposition of 2 fields for GPS elevation (one that has the > value and one the enumerates elevationUomId) > > Other ideas ? > > Jacques > PS : a simpler solution in my case (delivery issue) is to choice myself > a number, maybe 7777777 : can't be confused, easy to > remember.... but not to write, mmmm... 777 could do it ! Deregulation... > is that freedom ? GPS/Galileo is that future ? Will future > be freedom ? > >> -David >> >> > > > >
