|
From: Chris H. <ch...@op...> - 2003-05-14 20:55:57
|
I've been working with feature reading and some more, this time with multipolygons, and ran into a few problems. One that I fixed had to do with us not ending an attribute when we got a geometry from the sub handlers. The other is just what I think might be a bit better way of doing things. Instead of just looking in GMLFilterFeature to not use attributes that end polygonMember or StringMember (which doesn't even cover pointMembers), I made a MULTI_GEOMETRY_MEMBERS list of lineStringMember, polygonMember, and pointMember. The GMLFilterDocument checks if those come in, and does nothing (since the other code already handles the sub geometries). I'm not sure if this is the correct place for this to go, but I feel like having it in GMLFilterFeature isn't the right place for it, as those are geometry specific names. So my proposal is to put the attached class in, and get rid of the if (!localName.endsWith(polygonMember)... code. I think the GMLFilterDocument should always be a child of the Feature code, so it will always eat up the geometry specific member elements. Unless I'm thinking through this wrong... This is better for me since I'm currently forking GMLFilterFeature, since we still haven't put the hooks for attributeTypes in, and I need to filter filters up through my feature filter. Yes, I know the fork is bad, but I still haven't got a chance to work on gml filtering. But it seems like the process of ignoring the multi geometry members should happen before GMLFilterFeature. Chris |