Hey check out my proposal for splitting FeatureId and ResourceId on the other thread.
TIA, Gabriel On Wed, Oct 19, 2011 at 8:42 AM, Jody Garnett <jody.garn...@gmail.com> wrote: > Matches is supposed to check that a > feature matches. It is not used to compare identifiers. > > Thanks for the clarification however. > > I was going to have two implementations in order not to waste memory. > > Jody > > > On 19/10/2011, at 6:40 PM, Mark Leslie <mrk.les...@gmail.com> wrote: > >> I'm slowly coming round to the FeatureId option. I don't really like >> the idea of carrying around the extra version information when 98% of >> the time it's going to be placeholders, but it will keep client >> efforts cleaner. >> >> I should also clarify my confusion in comparing FeatureId to >> ResourceId. I basically wrote a test case that created a >> SimpleFeature with a FeatureId and saved it into the versioned store. >> On reading it out, I assertedEquals that they were the same. The >> versioned store created a ResourceId on read, so the >> ResourceId.equals(FeatureId) failed, yet the >> FeatureId.equals(ResourceId) succeeded. The FeatureId option would >> (should?) fail consistently both ways. >> >> There is an existing method that I simply didn't notice soon enough in >> Identifier.matches(..) that is the appropriate way to do things. I >> have no preference between equalsFid and matches, but equals should >> continue to be the same complete equality that caught me, ie. the >> proposed equalsExact. >> >> -- >> Mark >> >> On 19 October 2011 17:21, Jody Garnett <jody.garn...@gmail.com> wrote: >>> I am going to have a run at making a patch on Monday; if I can manage it I >>> would like to go with FeatureId option. If not I will use your ResourceId >>> option as a fall back position. >>> (I am not crazy I am going to start with your ResourceId patch and then >>> refactor; deprecating the non used RecordId and ObjectId as I go). All in >>> all I expect this to be a low risk change. >>> I am still keen to get feedback from Gabriel especially with respect the >>> functions that query based on time range. I am not sure I completely >>> understood what the wfs2 specification was on about here as they seemed very >>> vague. >>> -- >>> Jody Garnett >>> >>> On Wednesday, 19 October 2011 at 1:58 PM, Justin Deoliveira wrote: >>> >>> Thanks for putting the proposal together Jody. Tough to say which option is >>> the way to go.. I actually do like the option of just rolling all the >>> ResourceId stuff into feature id... seems a bit simpler and cleaner, and >>> definitely easy on client code to not have to do the instanceof check. >>> >>> On Tue, Oct 18, 2011 at 7:00 PM, Jody Garnett <jody.garn...@gmail.com> >>> wrote: >>> >>> Morning: >>> I have a development team that has been working in a fork of GeoTools while >>> the wfs2 and resoruceid concepts took shape. Justin has kindly merged in the >>> wfs2 work (I still need to write some docs before it is done); and I have >>> now written up a proposal for the ResourceId change. >>> - http://docs.codehaus.org/display/GEOTOOLS/ResouceId >>> Since I have a development team waiting on this I will start work on Monday; >>> and would like to collect any input people feel is necessary before that >>> time. The work should not take very long; there are however two options on >>> the table. >>> -- >>> Jody Garnett >>> >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure contains a >>> definitive record of customers, application performance, security >>> threats, fraudulent activity and more. Splunk takes this data and makes >>> sense of it. Business sense. IT sense. Common sense. >>> http://p.sf.net/sfu/splunk-d2d-oct >>> _______________________________________________ >>> Geotools-devel mailing list >>> Geotools-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> >>> >>> >>> -- >>> Justin Deoliveira >>> OpenGeo - http://opengeo.org >>> Enterprise support for open source geospatial. >>> >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure contains a >>> definitive record of customers, application performance, security >>> threats, fraudulent activity and more. Splunk takes this data and makes >>> sense of it. Business sense. IT sense. Common sense. >>> http://p.sf.net/sfu/splunk-d2d-oct >>> _______________________________________________ >>> Geotools-devel mailing list >>> Geotools-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> >> >> >> >> -- >> Mark Leslie >> Geospatial Software Architect >> LISAsoft >> >> ------------------------------------------------------------- >> Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61 >> Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009 >> ------------------------------------------------------------- >> >> LISAsoft is part of the A2end Group of Companies >> http://www.ardec.com.au >> http://www.lisasoft.com >> http://www.terrapages.com > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
