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
