Martin, I have looked at StAX and planned on using Sun's implementation. My code allows you to take information provided by the StAX parser to build in memory representations of an element and its content. The idea is you only put into RAM what you need. So, for our GML 2 example, I'll move through the file using StAX, but I will build an in-memory representation of each "current" Feature element.
This should give me the low-RAM consumption of an XML pull parsing technique, with the convenience of a DOM technique for just the current feature element I am working with. That's what I want to do in theory anyways. I still have to write the code and make it work. I'm in the middle of a PNEZD point reader/write plug-in for OpenJUMP that I want to get released first. The Sunburned Surveyor P.S. - Is your KML parsing code something we could hack to support KML in OpenJUMP? On Wed, May 20, 2009 at 1:12 PM, Martin Davis <mbda...@refractions.net> wrote: > Landon, > > Have you looked into the StAX API for XML pull-parsing? I'm using it to > parse KML, and it makes for fairly easy parser implementation (e.g. > recursive descent, which is the simplest for us humans to code up). > > http://en.wikipedia.org/wiki/StAX > http://woodstox.codehaus.org/ > > > Sunburned Surveyor wrote: >> I've looked at this problem, and I think it would be possible to write >> a fairly simple GML parser that didn't need a schema, as long as the >> GML file only contained features of one type. It would be possible to >> write the same type of parser for GML files that contain features of >> different types, but it would be more work. I would like to start with >> the simpler use case first. >> >> I wrote some simple code to replace JDOM, and a GML 2 parser would be >> a good test of it. Perhaps I could rearrange some priorities and get >> this busted out in the next couple of weeks. >> >> Landon >> >> On Wed, May 20, 2009 at 11:14 AM, Martin Davis <mbda...@refractions.net> >> wrote: >> >>> 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 >>> >>> >> >> ------------------------------------------------------------------------------ >> 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 > ------------------------------------------------------------------------------ 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
