On Mon, Nov 7, 2011 at 7:03 PM, Christopher Schmidt <crschm...@crschmidt.net> wrote: > On Mon, Nov 07, 2011 at 08:14:44AM -0800, Paul Ramsey wrote: >> EPSG:4326 was chosen as the "only mandatory projection" for OGC web >> services around 2000, five years before Google decided that >> not-quite-Mercator should be the new standard. >> >> It is also "unprojected", that is the units are latitude/longitude, so >> projecting it only requires a forward projection, while projecting >> not-quite-Mercator requires both an inverse projection into >> latitude/longitude and then a forward projection into your desired >> destination. >> >> As the units are latitude/longitude on WGS84, folks can easily match >> them to their handy GPS unit outputs. >> >> Whether 4326 is more or less f***ed up at the poles is a matter of >> debate, I suppose, but at a minimum it wastes fewer pixels on the >> north and can be used at slightly higher latitudes. > > This is the one that caused me to go with it. Storing Greenland in > EPSG:900913 is a big waste -- and more importantly, projecting backwards > from EPSG:900913 introduces more weird projection effects than going > the other way, in my experience working with it. (Going from EPSG:4326 > to a local projection generally worked fine; going from 900913 to > a local projection seemed, in a few limited cases, to be more > noisy). > > Since these images aren't designed to be consumed directly, really -- > that is, OAM archive images aren't meant to be read as tiles by web > clients -- using the format which is preferred by web clients seemed > unneccesary. Most local projections -- especially at northern latitudes > -- seem to be closer to EPSG:4326 than 900913, and you can get rid of > weird 'edge cases' with projecting near the poles: you can just > make requests for what is commonly thought of as the 'whole world' > rather than only being able to practically work up to some arbitrary > limit without getting really ridiculous.
Thank you (and Jim and Paul) for some logical reasons, most of which I understand. I guess the next question is: Is EPSG:4326 the only supported projection, the recommended projection, or just a suggested projection for OAM archival images? Like you said, what we're talking about is really archiving images, so if a data consumer has to reproject it shouldn't be our problem. Perhaps only allow projections with EPSG codes, or any valid PROJ.4 projection... -Josh > -- Chris > >> (Though storing >> northerly imagery in *either* 4326 or 3857 seems like a bad idea, IMO, >> given the distortions introduced and damage the resampling process >> therefore will do to the data.) >> >> So, I'd guess an answer would be: history; simplicity. >> >> All arbitrary decisions are arbitrary, but some are more arbitrary than >> others. >> >> P. >> >> On Mon, Nov 7, 2011 at 4:40 AM, Josh Doe <j...@joshdoe.com> wrote: >> > I've been trying to find the discussion or rationale for why EPSG:4326 >> > is the projection of choice (or only supported projection?), but >> > haven't had any luck. It seems to me that most imagery will eventually >> > be consumed in EPSG:3857/900913, though of course not exclusively, so >> > it seems that would be a better choice. Is there any technical reasons >> > why EPSG:4326 is preferred, or any statistics on it being more >> > prevalent? I think the answer to this belongs in the docs. >> > >> > Thanks, >> > -Josh >> > >> > _______________________________________________ >> > talk mailing list >> > t...@host134.hostmonster.com >> > http://host134.hostmonster.com/mailman/listinfo/talk_openaerialmap.org >> > >> >> _______________________________________________ >> talk mailing list >> t...@host134.hostmonster.com >> http://host134.hostmonster.com/mailman/listinfo/talk_openaerialmap.org > > -- > Christopher Schmidt > Web Developer > _______________________________________________ talk mailing list t...@host134.hostmonster.com http://host134.hostmonster.com/mailman/listinfo/talk_openaerialmap.org
