Hi, I'm wondering if there's any way to get a validity area for a generic transform, that is, a bbox in source coordinates telling me where the transform works, and were it starts failing.
I could use that to cut geometries that go beyond the limit and avoid: * making geometries disappear from rendering output, or, * trying to "skip" the non transformable points, with obvious topological problems (e.g., creating self intersecting rings, for example). Cheers Andrea ps: I'm also attaching a chat I had with Adrian on the subject, may be interesting. Basically, we think it possible to determine a validity area - from the projection classes themselves, since they know what equations they are using - by sampling (one time process, with cachable results...) (17:15:08) [EMAIL PROTECTED]/Gaim:* Hi Adrian (17:15:34) [EMAIL PROTECTED]:* hey (17:16:02) [EMAIL PROTECTED]/Gaim:* I tried to fix some problems with the demo code (17:16:14) [EMAIL PROTECTED]:* This is what google talk actually looks like!? (17:16:21) [EMAIL PROTECTED]:* primitive beyond belief (17:16:21) [EMAIL PROTECTED]/Gaim:* But I guess I created some as well (17:16:29) [EMAIL PROTECTED]:* hack away (17:16:30) [EMAIL PROTECTED]/Gaim:* Wait... (17:16:40) [EMAIL PROTECTED]/Gaim:* That's only the web version (17:16:46) [EMAIL PROTECTED]/Gaim:* and you can move it to its own window (17:17:00) [EMAIL PROTECTED]:* yeah, its there now (17:17:01) [EMAIL PROTECTED]/Gaim:* (the small popup is too small to be useful) (17:17:18) [EMAIL PROTECTED]/Gaim:* But then again, google has its own full fledged messenger (17:17:59) [EMAIL PROTECTED]/Gaim:* What IDE are you using btw? (17:18:11) [EMAIL PROTECTED]/Gaim:* The pom setups are problematic for Eclipse (17:18:45) [EMAIL PROTECTED]:* command line (17:18:57) [EMAIL PROTECTED]/Gaim:* ??? Don't believe this (17:18:58) [EMAIL PROTECTED]:* well, I use eclipse but don't have a working svn setup (17:19:10) [EMAIL PROTECTED]/Gaim:* Ah... (17:19:25) [EMAIL PROTECTED]:* and since i want to make sure the users can access the file from the command line (17:19:29) [EMAIL PROTECTED]:* I started there (17:19:39) [EMAIL PROTECTED]:* change stuff as you want (17:19:39) [EMAIL PROTECTED]/Gaim:* Anyway, I fixed the reprojection problems, for the moment (17:19:45) [EMAIL PROTECTED]/Gaim:* but still haven't committed (17:19:50) [EMAIL PROTECTED]:* the "project" button works? (17:19:52) [EMAIL PROTECTED]:* cool (17:19:56) [EMAIL PROTECTED]/Gaim:* and I'm nott too happy with the results... (17:20:09) [EMAIL PROTECTED]/Gaim:* basicaly soviet union and antartica disappear (17:20:17) [EMAIL PROTECTED]/Gaim:* because they do trigger reprojection errors (17:20:23) [EMAIL PROTECTED]/Gaim:* and there's no sane way I know of (17:20:44) [EMAIL PROTECTED]/Gaim:* to guess what a good "cookie cutter" is for the current projection (in a generic way I mean) (17:20:54) [EMAIL PROTECTED]:* can't you clip with a box around the pole first? (17:21:08) [EMAIL PROTECTED]:* two boxes around the date line (either side) (17:21:12) [EMAIL PROTECTED]:* and two around the poles (17:21:28) [EMAIL PROTECTED]/Gaim:* I tried, but there is no way to guess how far from the pole and date lines I should stay (17:21:41) [EMAIL PROTECTED]:* 178/88 (17:21:51) [EMAIL PROTECTED]:* but Martin should know (17:21:53) [EMAIL PROTECTED]/Gaim:* Not a good solution... (17:21:57) [EMAIL PROTECTED]/Gaim:* it's hard coded... (17:22:05) [EMAIL PROTECTED]:* that's fine (17:22:09) [EMAIL PROTECTED]:* it's a mercator (17:22:15) [EMAIL PROTECTED]/Gaim:* works for Mercator, may not work with others... (17:22:23) [EMAIL PROTECTED]:* no one in their right mind wants to see the mercator at the poles (17:22:29) [EMAIL PROTECTED]:* ah, you mean for all projections (17:22:34) [EMAIL PROTECTED]:* yes, that's harder (17:22:49) [EMAIL PROTECTED]/Gaim:* So nobody should provide data that touches the poles when using mercator :-) (17:23:11) [EMAIL PROTECTED]:* you can't have the renderer "keep going" when it causes a projection exception? (17:23:13) [EMAIL PROTECTED]/Gaim:* That's it: you should cut your original data if there is no general way to know a "safe area" for evey projection (17:23:19) [EMAIL PROTECTED]/Gaim:* It does (17:23:33) [EMAIL PROTECTED]/Gaim:* But the points are reprojected in one call (17:23:41) [EMAIL PROTECTED]:* it would still have to maintain topology (17:23:48) [EMAIL PROTECTED]:* which would be hard for antartica (17:23:52) [EMAIL PROTECTED]/Gaim:* So you either succeed in reprojecting a polygon, or not (17:23:59) [EMAIL PROTECTED]/Gaim:* that's why it disappears now (17:24:24) [EMAIL PROTECTED]:* you can't "shorten" the polygon, dropping the coordinates in the outline that are bad? (17:24:40) [EMAIL PROTECTED]/Gaim:* Heh... I may try, but it's a significant change in the code (17:24:44) [EMAIL PROTECTED] likes the issue, its deep, its GIS and we need to solve it (17:25:05) [EMAIL PROTECTED]/Gaim:* Now we do pass all the coordinates to the transformed at once for performance reasons (17:25:15) [EMAIL PROTECTED]/Gaim:* a call per point would have too much overhead (17:25:26) [EMAIL PROTECTED]:* a call per geometry (17:25:34) [EMAIL PROTECTED]/Gaim:* A call per "ring" (17:25:41) [EMAIL PROTECTED]:* since geometreies will be the basis of the next basis (17:25:44) [EMAIL PROTECTED]:* sure, per ring (17:25:53) [EMAIL PROTECTED]:* but you still have topology issues (17:25:53) [EMAIL PROTECTED]/Gaim:* Antartica is a single ring (17:26:01) [EMAIL PROTECTED]:* as you say (17:26:16) [EMAIL PROTECTED]/Gaim:* Yes, I could try to skip unprojectable point (17:26:25) [EMAIL PROTECTED]/Gaim:* but that would change the shape of what I'm projecting (17:26:29) [EMAIL PROTECTED]/Gaim:* in a very visible way (17:26:35) [EMAIL PROTECTED]/Gaim:* bbox cutting would be much better (17:26:41) [EMAIL PROTECTED]:* antartica's problem is not being near the pole (17:26:45) [EMAIL PROTECTED]/Gaim:* but I cannot determine the bbox in a geneal way (17:26:45) [EMAIL PROTECTED]:* but going around the world (17:27:02) [EMAIL PROTECTED]:* it needs to be cut at 180 degrees (17:27:13) [EMAIL PROTECTED]/Gaim:* In that file it's not going around (17:27:16) [EMAIL PROTECTED]/Gaim:* It's already cut (17:27:34) [EMAIL PROTECTED]:* and then become a box, that itself, *does* go near the pole (17:27:36) [EMAIL PROTECTED]/Gaim:* It's a shapefile, no knowledge of geographi coordinates (17:27:50) [EMAIL PROTECTED]:* 1) take ring (17:27:57) [EMAIL PROTECTED]/Gaim:* The real problem is that it touches the pole and the date lines... (17:28:04) [EMAIL PROTECTED]:* 2) eval if it has coordinates near the dateline/pole (17:28:14) [EMAIL PROTECTED]:* 3) *handle* if it does (17:28:21) [EMAIL PROTECTED]:* that (3) is beautifully hard (17:28:26) [EMAIL PROTECTED]/Gaim:* Handle how? That's the problem... (17:28:27) [EMAIL PROTECTED]/Gaim:* Indeed (17:28:42) [EMAIL PROTECTED] will think about it (17:29:00) [EMAIL PROTECTED]:* do you have a copy of the GHHS? (17:29:07) [EMAIL PROTECTED]:* global hieararchical shoreline (17:29:24) [EMAIL PROTECTED]:* it's a high quality shoreline database (17:29:26) [EMAIL PROTECTED]/Gaim:* I'm going to ask with a public mail, but I guess we won't get an answer... (17:29:33) [EMAIL PROTECTED]/Gaim:* I know it, but no, I haven't it (17:29:37) [EMAIL PROTECTED]/Gaim:* Why do you ask? (17:29:40) [EMAIL PROTECTED]:* should be a good test of whatever solution we come up with (17:30:13) [EMAIL PROTECTED]:* points: can be close to pole, cause no problems if dropped (17:30:21) [EMAIL PROTECTED]/Gaim:* Well, for the moment I'm going to commit the fix at the "feature" granularity, then let's see how can be handle that (17:30:46) [EMAIL PROTECTED]:* lines: can cross the dateline/wrap the poles; can be cut into line segements with segements near poles/datelines dropped (17:30:50) [EMAIL PROTECTED]/Gaim:* Yeah, lines should be cutted, and polygon clipped (17:31:11) [EMAIL PROTECTED]:* polygons: are ring structures, rings may overlap the dateline/poles (17:31:11) [EMAIL PROTECTED]/Gaim:* All that would be easy if we had a bbox for the current transform (17:31:25) [EMAIL PROTECTED]/Gaim:* remember that the problem is not the dateline itself, but the transform (17:31:47) [EMAIL PROTECTED]/Gaim:* because depending on that one you can touch the dateline or have to stay away from it (17:32:09) [EMAIL PROTECTED]/Gaim:* (same goes for the pole, think polar stereographic) (17:32:15) [EMAIL PROTECTED] always imagine that a generic gnu GIS should handle coordinates greater than 180 degrees (17:32:40) [EMAIL PROTECTED]/Gaim:* Acuster is going a bit too far now :-p (17:32:47) [EMAIL PROTECTED]:* no (17:33:05) [EMAIL PROTECTED]:* my ambition is a fundamental scientific block of code (17:33:16) [EMAIL PROTECTED]:* scientific code does not fail on trivialities (17:33:26) [EMAIL PROTECTED]/Gaim:* Adrian, this i s a big project... if we are not pragmatic we won't get anywhere... (17:33:28) [EMAIL PROTECTED]:* it fails where math/computers fail (17:33:47) [EMAIL PROTECTED]/Gaim:* You're not taking into account the resources needed to do that work (17:33:51) [EMAIL PROTECTED]:* we may have to work in 3D with quaternions (17:33:57) [EMAIL PROTECTED]:* but it should work (17:34:08) [EMAIL PROTECTED]/Gaim:* I'm never going to do such a code during weekends (17:34:20) [EMAIL PROTECTED]/Gaim:* And probaly TOPP won't pay me to do that (17:34:25) [EMAIL PROTECTED]:* andrea: the rule now is 'user clips before transform' which is fine if it's well adveritized (17:34:35) [EMAIL PROTECTED]/Gaim:* (I'm going to start working for TOPP October 1) (17:34:49) [EMAIL PROTECTED]:* and we know how to help the users find out what the issue is (17:34:51) [EMAIL PROTECTED]/Gaim:* yes, that's as much as we can do now (17:35:06) [EMAIL PROTECTED]:* as you say, the transform should have an "area of validity" (17:35:12) [EMAIL PROTECTED]:* which all the epsg transforms should have (17:35:24) [EMAIL PROTECTED]/Gaim:* They do? (17:35:33) [EMAIL PROTECTED]:* my code even has an approapriate line commented out (17:35:45) [EMAIL PROTECTED]:* yeah, in the metadata (17:35:57) [EMAIL PROTECTED]:* it's a String though, so it's hard to work against (17:36:09) [EMAIL PROTECTED]/Gaim:* Ah... (17:36:19) [EMAIL PROTECTED]/Gaim:* Human readable, not parsable? (17:36:39) [EMAIL PROTECTED]:* yeah, and up to the authority to decided on (17:36:52) [EMAIL PROTECTED]/Gaim:* Hum, that's interesting... (17:36:54) [EMAIL PROTECTED]:* so it could be 'Mercator is valid everywhere except near the poles (17:37:02) [EMAIL PROTECTED]:* which you can't parse (17:37:09) [EMAIL PROTECTED]/Gaim:* Grr... (17:37:41) [EMAIL PROTECTED]/Gaim:* Too bad... (17:37:45) [EMAIL PROTECTED]:* projection rules aren't that hard though (17:38:16) [EMAIL PROTECTED]:* it' all comes to turning the globe into a rectangular strip of some kind (17:38:39) [EMAIL PROTECTED]:* ah, but then we can't handle arbitrary transforms (17:39:03) [EMAIL PROTECTED] wants to make a shift transform that slides all the data up and to the left (17:39:11) [EMAIL PROTECTED]:* which means the south pole is undefined (17:39:18) [EMAIL PROTECTED]:* and we loose data off the top of the world (17:39:26) [EMAIL PROTECTED]:* but it should be doable (17:39:51) [EMAIL PROTECTED]:* andrea: I'm going to play with this for a little while and see where I fail to find an algorithm (17:40:01) [EMAIL PROTECTED]/Gaim:* Ok, good (17:40:04) [EMAIL PROTECTED]/Gaim:* Let me know (17:40:05) [EMAIL PROTECTED]:* thanks for looking at the problem (17:40:15) [EMAIL PROTECTED]/Gaim:* No problem my pleasure :-) (17:44:59) [EMAIL PROTECTED]/Gaim:* By the way, this dicussion is interesting... can I post it to the ml? (17:49:27) [EMAIL PROTECTED]:* oooh, fake data (17:49:37) [EMAIL PROTECTED]/Gaim:* ? (17:49:40) [EMAIL PROTECTED]:* you run a first transform with a standard, fake data set (17:50:03) [EMAIL PROTECTED]:* points all over and rings that cross the dateline, circle the poles (17:50:16) [EMAIL PROTECTED]/Gaim:* Arg... you want to determine area by sampling? (17:50:29) [EMAIL PROTECTED]:* then you figure out a bounding box from what's tossed out (17:50:33) [EMAIL PROTECTED]:* yeah, sampling (17:50:43) [EMAIL PROTECTED]/Gaim:* Sloooow... (17:50:44) [EMAIL PROTECTED]:* andrea gets 2 points (17:50:49) [EMAIL PROTECTED]:* not really (17:51:05) [EMAIL PROTECTED]:* it would be 5000 points (17:51:07) [EMAIL PROTECTED]:* or so (17:51:23) [EMAIL PROTECTED]:* and you only need to do it the first time you use that transform (17:51:24) [EMAIL PROTECTED]/Gaim:* Hmm... I'm wondering if some funky projection could have unprojectable "holes" ;-) (17:51:39) [EMAIL PROTECTED]:* open an modern atlas (17:51:50) [EMAIL PROTECTED]:* that's all the projections we need to handle (17:52:11) [EMAIL PROTECTED]:* well, we need to create a bunch of them as well (17:52:56) [EMAIL PROTECTED]:* (yes, do whatever you want with my IRC rants; they cannot lose value to me by being posted) (17:53:27) [EMAIL PROTECTED]:* we would need a field in the transform that tells us we've dealt with it (17:53:41) [EMAIL PROTECTED]:* that may simply be that its bbox is defined (17:53:41) [EMAIL PROTECTED]/Gaim:* Anyway, if we assume sane projections, they usually have a rectangular validity area (in lat/lon coords) (17:53:59) [EMAIL PROTECTED]:* isn't that general? (17:54:21) [EMAIL PROTECTED]:* even a projection that loops the world several times (aka sattelite push broom) (17:54:24) [EMAIL PROTECTED]/Gaim:* But the best would be to generate a polygon that connects the outer bondary of projectable points... (17:54:39) [EMAIL PROTECTED]:* still ends up with a rectangular area (17:54:54) [EMAIL PROTECTED]/Gaim:* It may be or not... (17:54:56) [EMAIL PROTECTED]:* that we would have to project piecewise (17:55:00) [EMAIL PROTECTED]:* cool (17:55:18) [EMAIL PROTECTED]:* the problem gets even richer (17:55:38) [EMAIL PROTECTED]/Gaim:* Anyway, since all projections do have a class for them, it's possible to have them return a validity area (17:55:44) [EMAIL PROTECTED]/Gaim:* (an "exact" one) (17:56:08) [EMAIL PROTECTED]:* we should be able to leverage the math in the transform itself (17:56:24) [EMAIL PROTECTED]/Gaim:* Yep, that's the idea more or less... (17:56:28) [EMAIL PROTECTED]:* but we need martin for that since he's the only one who has a grasp of how the equations work ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
