Good points, RJ. AFAIK it's quite tricky to "guess" how to extract meaningful data from GML. Also, we wanted to make sure that we provided a fully general facility to let users extract whatever data they needed from their GML document (although as I said, this function didn't get a whole lotta lovin').
I'll have to have a look at OGR and see what their "secret sauce" is! Rahkonen Jukka wrote: > Hi Martin, > > This is not so serious for me any longer. I tend to get tired fast and try to > find other usable ready made solutions. I have found that usually I will do > fine with ogr2ogr program which is rather good in guessing GML. My main > point was that this input/output template system is not extremely easy to > learn and beginners willing just to read in some odd GML would probably be > ready sooner if they find some way for converting the data first to > shapefiles. But if there is a atable production environment and data in the > same fixed GML format will be used frequently then it pays better to make > those templates. This said, it might be good to have in addition to the > documentation a small real GML dataset and templates which work with that > downloadable somewhere so template writers could use those as example. > > -Jukka- > > Martin Davis wrote: > > >> RJ, sorry you're having such a frustrating time. I'm sure there's much >> better ways the GML I/O support could have been designed - it was done >> in a hurry, to meet a pretty specific use case. There may also be bugs >> in the codebase, which is possibly what you're running into. >> > > >> However, until someone has the time & ideas to write something better, >> that's what we're stuck with. :-( >> > > >> Why don't you post a sample GML file and your template, and maybe >> someone (maybe even me!) will be able to figure out how to get it to work? >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > -- Martin Davis Senior Technical Architect Refractions Research, Inc. (250) 383-3022 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
