The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I have tests in place for the current methods, so it should not be to hard to refactor without breaking anything. However, I have at couple of problems as how to structure the whole thing.

- Does all calculations belong in the same class?
- There is not much error checking. Should I introduce some exceptions? (pretty new to this concept, so an example would be nice)
- How would you like to use a class like this?
- Shouldn't I have more methods return something instead of the current setting of variables?

At the least give each coordinate type a different class with a common interface. You might want to look at PEAR:ate to see how they handle different calendars. And you might also want to have a standard coordinate system (lat/long?) and convert every other system to that so calculations can be handled uniformly.

- There is not much error checking. Should I introduce some exceptions? (pretty new to this concept, so an example would be nice)

Depends on how critical the state of the class can be when something messes up. But my guess is that providing a means to validate the data in the class would suffice.

- How would you like to use a class like this?

- With knowing the least math as possible.
- Letting me do common things easily (create some use cases).

- Shouldn't I have more methods return something instead of the current setting of variables?

In this case that would make sense, the calculations are hardly worthy of being object state.

the visitor should be getting access to data through $obj->getSomeData().
conversions need to take place inside the data object... since conversions might need other properties inside the object which the visitor shouldn't have access to.

somewhat

having $renderer->update($this);
makes your current object very delicate. your logic needs to be adjusted

for every point you should be able to get
getLatitude
getLongitude
getNorthing
getEasting
getZone

no need to run update.
and it should be $visitor->visit($this);

///basic api of a visitor renderer

$visitor = new specificvisitor();
... set visitor properties if you need to

$mainobject = new mainobject();
$mainobject->render($visitor);

echo $visitor->display();

---- actually i revisited your post...
looks like you got it correct. my mistake. -
I always call display on my visitor.. you did it inside... good job.
but i would change update($this); to visit($this)
would have made it clear on my end. for a minute there i thought you were updating your data object.. just because of a new display.

// I know the names need to be changed to reflect more precisely what// is returned, but for the example I just use the function names in the// current implementationecho $gpoint->getE(); // getting UTM Eastingecho $gpoint->getN(); // getting UTM Northingecho $gpoint->getZ(); // getting UTM Zone

Do I undertstand you correctly that you would keep all conversion methods in the class Math_GeographicPoint.

yes

Would you just instantiate the class, like it is now?

no. how can you create an empty geopoint?
new Math_GeographicPoint();
// I normally have ArgumentExceptions if you try to instantiate an object with bad parameters.
// someone can call $gpoint->getE(); before you even set data.
to delicate for my taste.

should be:
new GeographicPoint(lat, long)
new GeographicPoint('string address')

you shouldn't need $gpoint->convertLLToUTM(); if you go my route.

because once you instantiate the object you can safely call all of these functions:
getLatitude
getLongitude
getNorthing
getEasting
getZone

convert back and forworth

data in UTM and not in longitude or latitude or even an address

when you construct your object... you need to grab all fields to populate the get... functions.

I haven't studied this area enough .. i had to look up crux cute ... but you should be able to convert back and forworth.. example in the past i used a webservice to convert between address to lat and long and vice versa.

no i don't agree when your createFrom approach..
because I want access to
getLatitude
getLongitude
getNorthing
getEasting
getZone

all those functions once the object is created. so you need a conversion mechanism built into your object.

if its not a simple numeric calculations then create a private variable for lat, long, northing, easting, zone; and in your constructor do all the expensive operation to find all the values... if a webservice cache a serialized result set.

Yeah, I know that I need to access all of those variables through getLatitude() etc. when the object is created. But I also need to create the geographic point somehow, and suppose I only have UTM values.

I can only have one constructor How would you construct the object?

Essentially the object has to be able to handle the following coordinate sets:

However, there is also a problem with this approach. To get Lambert coordinates you need to do a lot of setup. In the current implementation through Math_GeographicPoint::configLambert. But if I never need Lambert, that would be pretty annoying to have to set GeographicPoint up to handle this. How can one handle a special case but still keep the basic object consistent and usable? (that is the conversion between LatLong og UTM)

builder pattern

i take that approach in my calendar component
function __construct($object)
but its because i implement a builder pattern.

new Calendar(new GregorianCalendar())

//its not about providing a nice constructor;
you move to that step when you truelly have a totaly new object type.. not for a nice constructor. Example gregorian calendar uses a totally different set of calculations then another type of calendar. But all have similar concepts that can be implemented through a builder interface.