On Jul 12, 2010, at 06:45 , Gabriel Roldan wrote: > On 7/9/10 5:25 PM, Andreas Hocevar wrote: >> Hi, >> >> just a quick note to let you know that proj4js can do lazy loading of >> crs definitions. >> >> But I doubt that we will be using projections other than 900913 in >> the map viewers, because 900913 is our only option if we want to use >> Google layers (and OSM if we don't want to provide our own tileset). > But there may be the case that the user doesn't care about google layers > nor OSM ones, he just want to use data from his municipality's WMS, but > the WMS doesn't support 900913. If GeoNode doesn't support the CRS the > data is published in, then he can't use the data at all. Then GeoNode is > useless.
Good point. Tim and I have been talking about some kind of "CRS negotiation", meaning the client has to figure out the common denominator of available CRS of all layers added to a map, and warn about layers that have to be removed because they don't match the CRS of other layers. > That's exactly what happened to me and why I opened that ticket. > > Aside: the whole question arises from the fact that we're storing the > center point of the map in 4326, then who performs the transformation to > Map's CRS. Wouldn't make more sense to store the map's center point in > the Map's CRS to start with? (I don't know about the internals of this > design decision so excuse me if I'm missing something obvious.) I was thinking along the same lines when I wrote my initial reply, but considered the fact that the coordinates are stored in 4326 as engraved in stone. But you are right, as long as we don't search maps (only layers) by location, storing the map bounds/center in map CRS coordinates would solve the problem, and make map persistence 100% compatible with the gxp viewer. -Andreas.
