Has anyone looked at the GeoTools GML reader, to see if it's a reasonable thing to include with OJ?
Writing GML readers is not a trivial task - that was why we went with the template idea (so as to push the complexity back onto the human). There might be some simpler approaches that could be looked at, though - such as pre-scanning the GML file to try and deduce the Feature tag, attribute tags & types, and the geometry tag. It would be an interesting project... I'd be surprised if someone hasn't already worked on this. OGR is another possible model to follow - not sure what they do for parsing GML. The thing that seems really difficult to do is to analyze the schema and use that to direct the parsing - that is basically equivalent to writing a parser generator, which is a non-trivial task. Sunburned Surveyor wrote: > I understand the concern about adding a big library to OpenJUMP. I do > plan on adding CRS capability to OpenJUMP (sometime this year?) and I > have already started putting together the dependencies for the CRS > code. > > I wouldn't be against just splitting out the packages we need to use > from the bigger deegree Project libraries, as long as this doesn't get > ridiculous. I suppose we can see how this goes with the CRS code. > > I don't know if it is worth integrating the degree libs for the GML > parser. I think we can probably whip up our own lightweight solution > to this problem. > > The Sunburned Surveyor > > On Wed, May 20, 2009 at 1:14 AM, Andreas Schmitz <schm...@lat-lon.de> wrote: > >> Stefan Steiniger wrote: >> >>> Michaël Michaud wrote: >>> >> Hi, >> >> >>>> Here are my thoughts about the question : >>>> - Andreas is one of the main contributors of the project, so his own >>>> advice about what is good for OpenJUMP is much welcome >>>> >> thanks, although I don't feel like I've been contributing much lately... >> >> >>>> - I wouldn't like to see big libraries added to openjump just to be able >>>> to use a few classes of those libraries, but small packages to add >>>> capabities to OJ are OK >>>> >> Yes, that's why I'm also hesitating a little (see below). >> >> >>>> - To answer more precisely, It would be interesting to know >>>> if deegree code should be included as a whole or on a per package basis >>>> what would be the size and the potential of each package for OpenJUMP >>>> what would be the redundances with existing OJ code (which may need >>>> to clean some parts of existing code...) >>>> >> I think that would be fairly difficult and not worth it. Once the GML >> parsing is >> used, you use a major part of deegree (feature model, CRS, GML model, >> geometry >> model etc.), so that copying over only required packages makes it virtually >> impossible to keep in sync with the code base. >> >> >>> Yep, Michael summarizes it very well. >>> I'm also a hesitating to add a big lib of which we may use only a few >>> things. Although deegree may offer a lot of functionality for the future >>> (GML and CRS wise and the extended feature model?). >>> >> I have to agree with you here as well. If we'd have some funding to integrate >> reprojection based on deegree in OpenJUMP, I'd certainly opt for 'yes'. If we >> 'only' want GML, I'd opt for 'maybe yes'. >> >> There are certainly a LOT of ideas where deegree code could be used to >> improve >> OpenJUMP (think WCS client, access to all data sources raster/vector that >> deegree can use), but any of them would require some work to implement and >> make >> stable. >> >> >>> Does it actually make a difference in terms of memory footprint, i.e. >>> are all deegree classes loaded? >>> >> Only classes that are actually used are loaded. If the user does not use any >> functionality that uses deegree, no deegree class is loaded at all. >> >> Best regards, Andreas >> -- >> l a t / l o n GmbH >> Aennchenstrasse 19 53177 Bonn, Germany >> phone ++49 +228 18496-0 fax ++49 +228 1849629 >> http://www.lat-lon.de http://www.deegree.org >> ------------------------------------------------------- >> OpenStreetMap im Rheinland - May 26th >> deegree day 2009 - May 27th >> http://deegreeday.deegree.org >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.9 (GNU/Linux) >> >> iEYEARECAAYFAkoTu9gACgkQ737OVr+Ru7rdXgCfal7ZpzSc/Jqo6bG3vL4UsGTU >> AUkAn2ry5cfIpNOfBzJ7T8aFhaOsl0aC >> =5U1K >> -----END PGP SIGNATURE----- >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables >> unlimited royalty-free distribution of the report engine >> for externally facing server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> >> > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > 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 ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
