On Mon, May 28, 2012 at 11:27 AM, Andrea Aime
<[email protected]>wrote:

> On Mon, May 28, 2012 at 7:14 PM, Justin Deoliveira <[email protected]>
> wrote:
> >> I've made the change straight away because of two reasons:
> >> - it makes the GUI unusable if you have lots of those layers and need to
> >>  change bits in the configurations (the delay happens at each save, not
> >>  only when doing the first insert)
> >> - rest-config clients need to be prepared to accept WKT anyways, since
> >>  not all .prj files in the world can be matched ot a EPSG code, even
> >>  after a full scan
> >
> >
> > Yup, makes sense, aware of the problem, just don't think the fix is that
> cut
> > and dry.
>
> I can go for that, though I don't understand how it changes on the rest
> clients
> side, since it merely changes a likeliness of getting the code, not
> the fact that
> the client is broken if it cannot handle WKT too.
>

Well from my point of view this could be viewed a regression. WKT that we
could map to an srs code automatically before is now not occurring.


> There is however a timing issue:
> - Rolling back the fix is going to make GS unusable again for GUI people
> that
>  happen to hit the issue described in the jira (which I've fixed because
> I've
>  been bitten by it multiple times in the past, and in a very severe
> way yesterday)
>

Given that I have not heard anyone complain about this I feel stating that
it makes the GUI "unusable" is an overstatement. That code has been in
place for years. Although admittedly i don't monitor the user list, irc,
and jira as closely as others.


> - I cannot work on an alternative approach till next weekend (I'm going to
> be
>  away for a few days)
> - 2.1.4 may be coming out this week
>
> Well i am happy to try to help come up with the patch. I don't know the
referencing system very well but my idea was just a simple fixed sized
thread safe set that kept recently looked up CRS objects around. Then in
CRS.lookupEpsgCode when the fast path fails scan through the second level
cache and do the comparison. If that fails fall back to the full scan. If
that sound sane I will proceed. One question i have is whether the second
level cache should be used when fullScan = false?

If not sane please advise.

Hmm... what to do?
>
> Cheers
> Andrea
>
> --
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:      +39 0584 962313
> mob:    +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>



-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to