Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better all-round 3D support #53

Open
wants to merge 14 commits into
base: master
Choose a base branch
from
Open

Better all-round 3D support #53

wants to merge 14 commits into from

Conversation

phayes
Copy link
Owner

@phayes phayes commented Aug 31, 2012

No description provided.

@phayes
Copy link
Owner Author

phayes commented Aug 31, 2012

To Do:

  1. provide a "flatten" method.
  2. Decide how to want to handle 3D geoms for methods such as length, distance etc.

@mkdgs
Copy link

mkdgs commented Sep 1, 2012

i think distance and length is trivial
http://en.wikipedia.org/wiki/Euclidean_distance

and intersect and other a little bit harder ...

postgis has a separate some 3D function (like distance3D)
http://postgis.refractions.net/docs/reference.html#Geometry_Constructors

i don't know how is work in GEOS, but it may be more "backward compatible" to separate 3d function

@phayes
Copy link
Owner Author

phayes commented Sep 1, 2012

I think it's definitely a good idea to separate out the 3D stuff into different functions. I checked with GEOS people on IRC, looks like it only support 2D.

@phayes
Copy link
Owner Author

phayes commented Sep 2, 2012

The start of the PHP-native distance calculations are in place. "distance is trivial" my ass! :-P

I'm still running into some problems with divide-by-zero errors that I need to investigate.

@phayes
Copy link
Owner Author

phayes commented Sep 2, 2012

Now that I've properly implemented distance in 2D, I'm beginning to realize how out of my league I am for implementing the same in 3D.

Problems for 3D distance:

  1. line-segments could be closest anywhere along the curve (not just at an endpoints as in 2D).
  2. We would need a 3D intersects method, including detecting if two polygons intersect in 3D space.

@phayes
Copy link
Owner Author

phayes commented Sep 5, 2012

Hi @mkdgs,

I definitely appreciate where your coming from. The problem is that if we were to implement it this way and removing all these non-universal methods from the parent classes will involve a lot of code duplication in child classes.

I wish there was a way you could have a child-class "undeclare" a method.

I wonder if there is a way we can both be happy by using traits instead of direct inheritance?

In either case, can we not deal with these issues in this pull-request? Let's keep to the existing pattern (with all it warts) for the 3D stuff, and deal with how we do method inheritance in a separate issue?

@phayes phayes mentioned this pull request Sep 5, 2012
@mkdgs
Copy link

mkdgs commented Sep 5, 2012

thanks @phayes,

it may be for the future of geoPHP. for now just i have only moved the methods of Point.

take a look into Simple Feature Access at http://www.opengeospatial.org/standards/sfa
there is a lot of good things inside :-)

@phayes
Copy link
Owner Author

phayes commented Sep 5, 2012

I'll check that out @mkdgs . Thanks for the link.

@phayes
Copy link
Owner Author

phayes commented Oct 20, 2012

I've started testing this and I'm running into all sorts of errors when I run the tests.

  1. GeoRSS adapter: "Invalid GeoRSS".
  2. WKB adapter: "truncated data"

I'm going to try to correct these errors.

@mkdgs
Copy link

mkdgs commented Oct 20, 2012

hello phayes,
take a look on my repo, i have made many fix/change

@phayes phayes added this to the Version 2 milestone Jun 29, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants