On 07/12/2010 01:15 PM, Gabriel Roldan wrote: > On 7/12/10 4:48 AM, Andreas Hocevar wrote: > >> 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. >> > that would be (_IMHO_) step in doing it the right way. And it doesn't > preclude the ability to make map searches by map bounds in the future, > if we need to. > There may be a couple options: > - A Map may have it's own metadata record, where lat lon bounds is > already there to be used on spatial searches > - we may have our own database of maps, where we could search by > something like toWGS84(mapbounds) overlaps my bounds. > > Gabriel > > >> -Andreas. >> > > This sounds good to me, we can just punt on the reprojection-in-python issue for now. We do still need to handle a reprojection/migration on the live site, but someone (me maybe?) can script that from outside the Django webapp.
Here's the current set of fields on a Map: title = models.CharField abstract = models.CharField contact = models.CharField featured = models.BooleanField endorsed = models.BooleanField zoom = models.IntegerField center_lat = models.FloatField center_lon = models.FloatField owner = models.ForeignKey I guess we should rename center_lat and center_lon to center_x and center_y, and add a display_srid field to track the display projection? On the other hand, as long as we are migrating all this stuff, we could replace the (center + zoomlevel) model with just a bbox. Zoom levels seem a bit vague in the face of arbitrary projections, unless I am mistaken. Opinions? -- David Winslow OpenGeo - http://opengeo.org/
