Hi, Jody Garnett a écrit :
> Hi Pierrick - welcome Thanks. > Comments inline. Cool :-) >> First, let me introduce myself : I'm one of the developers of >> eXist,an open source native XML database >> (http://exist.sourceforge.net/). In order to make a >> proof-of-concept for our new modularized indexes, I'm currently >> working on implementing spatial indexes for GML files. >> > Nice stuff. Reformulating : for GML-namespaced geometries contained in XML files. In clear, I just want to index the geometries. Other XML info will be handled by eXist. >> So my question is about the present and future of Geotools's GML >> stuff and, in particular about this long-standing issue : >> >> http://codehaus01a.managed.contegix.com/browse/GEOT-742 >> >> > Before I start I would like to introduce you to the following page. - > http://docs.codehaus.org/display/GEOTDOC/08+XML That's the page from which I started :-) > As you read that you can see there are four parsers avaialble to you. > May I recommend you use the one Justin is working on? Which is ? > We really would like to throw away these SAX and DOM parsers as soon > as possible. Doh ! In an XMLDB indexer, a SAX parser might be useful you know :-) Anyway, which parser should I choose to parse GML geometries ? Any javadocs ? Snippets ? >> ... which makes detection of "wrong" geometries more difficult that >> it needs to be (not counting the hard-coded messages on >> System.err). >> >> Implementing this RFE would also make my life easier :-) : >> >> http://codehaus01a.managed.contegix.com/browse/GEOT-1239 >> > I would not expect any action on this - simply because it is a case > Justin's parser handles well. OK. Same question : I've been unable to find a code snippet from where I could get inspiration. > Even a ready to go test case can help so we can run through it in a > debugger. My first issue has a code snippet and test files that triggers the NPE. >> Usually, I would have filled patches, just like an open source >> developer should do but I still have some difficulties to master >> Geotools's development process (namely Maven). >> > Ah ... well if you can get the code to go in eclipse a patch from > there will also work. For sure but your code still can't go into my Eclipse :-) > If you jump on the #geotools channel we can also talk you through > maven build questions (last week was a bit of a mess but normally the > build is fine). I will but, frankly, adding Maven learning to my current problems scares me :-) However, my questions were rather about Geotool's future. Is it worth the value to try to improve these parts of the code that, if I understood well, are already legacy code ? Also, how modularizable will be Geotools in the future ? Should I use huge (well, I guess) libraries with powerful schema-driven feature capabilities when I "just" want to parse XML geometries ? Maybe I haven't understood well what the new stuff is going to be and how GML will be handled. I'd be grateful if someone could clarify. Cheers, p.b. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
