Re: [Geotools-devel] Improving parsing GML files without a reference to the schema

[Andrea Aime]

On Tue, Feb 9, 2016 at 8:19 PM, Jody Garnett  wrote:

> Wonder if that is a functionality change since I wrote
> GML.decodeFeatureCollection (hard to know).
>

Don't know honestly...

Anyways, I wanted to make a pull request, but I pushed to master instead...
oh well, review
still welcomed:

https://github.com/geotools/geotools/commit/11b29db7fef74275568a6c5a9b3cf5fb4fa32c99

Cheers
Andrea


-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

---
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Improving parsing GML files without a reference to the schema

[Jody Garnett]

Wonder if that is a functionality change since I wrote
GML.decodeFeatureCollection (hard to know).

Still the point of a facade class is to hook up these methods to the best
available implementation, and the changes you are making sound like an
improvement.

--
Jody Garnett

On 5 February 2016 at 10:28, Andrea Aime 
wrote:

> On Fri, Feb 5, 2016 at 7:25 PM, Jody Garnett 
> wrote:
>
>> Looks like from your code example that you are doing a much smarter job
>> then the GML
>> 
>> utility class  decodeFeatureCollection(InputStream in) method.
>>
>
>> When a schema is not available the parser returns a stream of
>> Map entries. The simpleFeatureCollection( collection method)
>> uses uses simpleType(Object)
>> 
>> to generate a schema for the first parsed Map, and then
>> creates the features based on that.
>>
>
> I am actually getting back a SimpleFeatureCollection regardless, it's just
> that it's limited to the attributes
> of the first feature (see my first mail for a description of the original
> problem).
>
>
>>
>> Once your new code is ready I would like to update
>> GML.decodeFeatureCollection( InputStream ) to use it.
>>
>
> I could go for that, sure
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or for other risks which arise as a result of
> e-mail transmission, viruses, etc.
>
> ---
>
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Improving parsing GML files without a reference to the schema

[Jody Garnett]

Looks like from your code example that you are doing a much smarter job
then the GML

utility class  decodeFeatureCollection(InputStream in) method.

When a schema is not available the parser returns a stream of
Map entries. The simpleFeatureCollection( collection method)
uses uses simpleType(Object)

to generate a schema for the first parsed Map, and then
creates the features based on that.

Once your new code is ready I would like to update
GML.decodeFeatureCollection( InputStream ) to use it.


--
Jody Garnett

On 31 January 2016 at 01:37, Andrea Aime 
wrote:

> On Fri, Jan 29, 2016 at 4:00 PM, Justin Deoliveira 
> wrote:
>
>> These could be added as new methods to the GML facade class:
>>> SimpleFeatureType GML.decodeSchema(InputStream in)
>>> SimpleFeatureCollection GML.decodeFeatureCollection(InputStream in)
>>>
>>> I wonder if you could handle both the scan only single feature vs scan
>> full feature collection with a single additional integer argument. The
>> argument would be the number of features to “pre-scan” to compile the
>> schema. This would allow for a bit more control for larger GML collections
>> where you might not want to scan the whole collection but you want to scan
>> more than just the first. Just a thought.
>>
>
> I'm a bit perplexed... like, it seems to me the two significant values
> would be "1", aka "no null values, my collection is fully uniform" and "0",
> aka "no clue, scan till the end", when you don't know
> where the "odd one out" would be.
> I do realize that most of the time scanning the first few features would
> give you the final schema, but there is no reliability regarding the
> number of features where this happens, the odd case out being exactly the
> one where the attribute shows only in the last
> features of the series (which happens if you do a "order by myAtt desc" in
> a sql query, the null values are packed at
> the beginning of the series).
>
> So, let me show you what I did in my little experiment, this will also
> explain why I was talking about pull
> parsing :-)
>
> My starting point is a desire to parse a feature collection in GML, and
> get back a SimpleFeatureCollection
> (streaming is not a requirement here). So I started using a normal Parser,
> which gives me back the SimpleFeatureCollection.
>
> However, noticed that the FeatureTypeCache was caching the type of the
> first feature... I then injected in the
> pico context a subclass that would not cache, and then
> DefaultFeatureCollection would start complaining in
> the logs that the features being inserted into it are not a match for its
> feature type (determined from
> the first feature).
>
> So ok, I decided to give the pull parser a try, that does not use a
> collection... here is the result:
>
> ---
>
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.FileNotFoundException;
> import java.io.IOException;
>
> import javax.xml.stream.XMLStreamException;
>
> import org.geotools.gml2.FeatureTypeCache;
> import org.geotools.gml3.GMLConfiguration;
> import org.geotools.xml.PullParser;
> import org.opengis.feature.simple.SimpleFeature;
> import org.opengis.feature.type.FeatureType;
> import org.xml.sax.SAXException;
>
> public class GMLPullParserReader {
>
> /**
>  * Does not cache the feature type, allowing each feature to have its
> own
>  */
> private static final class FeatureTypeCacheNone extends
> FeatureTypeCache {
> @Override
> public void put(FeatureType type) {
> // no op
> }
> }
>
> public static void main(String[] args) throws XMLStreamException,
> IOException, SAXException {
> pullParse(new File("/tmp/GetFeatureResponse1.xml"));
> pullParse(new File("/tmp/GetFeatureResponse2.xml"));
> }
>
> private static void pullParse(File input)
> throws FileNotFoundException, XMLStreamException, IOException,
> SAXException {
> GMLConfiguration configuration = new GMLConfiguration();
> PullParser parser = new PullParser(configuration, new
> FileInputStream(input), SimpleFeature.class);
> parser.setContextCustomizer(context -> {
> Object instance =
> context.getComponentInstanceOfType(FeatureTypeCache.class);
> context.unregisterComponentByInstance(instance);
> context.registerComponentInstance(new FeatureTypeCacheNone());
> });
> SimpleFeature f = null;
> while((f = (SimpleFeature)parser.parse()) != null) {
> System.out.println(f.getFeatureType());
> }
> }
> }
>
> ---
>
> The two collections have features in different orders, 

Re: [Geotools-devel] Improving parsing GML files without a reference to the schema

[Andrea Aime]

On Fri, Feb 5, 2016 at 7:25 PM, Jody Garnett  wrote:

> Looks like from your code example that you are doing a much smarter job
> then the GML
> 
> utility class  decodeFeatureCollection(InputStream in) method.
>

> When a schema is not available the parser returns a stream of
> Map entries. The simpleFeatureCollection( collection method)
> uses uses simpleType(Object)
> 
> to generate a schema for the first parsed Map, and then
> creates the features based on that.
>

I am actually getting back a SimpleFeatureCollection regardless, it's just
that it's limited to the attributes
of the first feature (see my first mail for a description of the original
problem).


>
> Once your new code is ready I would like to update
> GML.decodeFeatureCollection( InputStream ) to use it.
>

I could go for that, sure

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.



The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

---
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151=/4140___
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Re: [Geotools-devel] Improving parsing GML files without a reference to the schema

[Andrea Aime]

On Fri, Jan 29, 2016 at 4:00 PM, Justin Deoliveira 
wrote:

> These could be added as new methods to the GML facade class:
>> SimpleFeatureType GML.decodeSchema(InputStream in)
>> SimpleFeatureCollection GML.decodeFeatureCollection(InputStream in)
>>
>> I wonder if you could handle both the scan only single feature vs scan
> full feature collection with a single additional integer argument. The
> argument would be the number of features to “pre-scan” to compile the
> schema. This would allow for a bit more control for larger GML collections
> where you might not want to scan the whole collection but you want to scan
> more than just the first. Just a thought.
>

I'm a bit perplexed... like, it seems to me the two significant values
would be "1", aka "no null values, my collection is fully uniform" and "0",
aka "no clue, scan till the end", when you don't know
where the "odd one out" would be.
I do realize that most of the time scanning the first few features would
give you the final schema, but there is no reliability regarding the
number of features where this happens, the odd case out being exactly the
one where the attribute shows only in the last
features of the series (which happens if you do a "order by myAtt desc" in
a sql query, the null values are packed at
the beginning of the series).

So, let me show you what I did in my little experiment, this will also
explain why I was talking about pull
parsing :-)

My starting point is a desire to parse a feature collection in GML, and get
back a SimpleFeatureCollection
(streaming is not a requirement here). So I started using a normal Parser,
which gives me back the SimpleFeatureCollection.

However, noticed that the FeatureTypeCache was caching the type of the
first feature... I then injected in the
pico context a subclass that would not cache, and then
DefaultFeatureCollection would start complaining in
the logs that the features being inserted into it are not a match for its
feature type (determined from
the first feature).

So ok, I decided to give the pull parser a try, that does not use a
collection... here is the result:

---

import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;

import javax.xml.stream.XMLStreamException;

import org.geotools.gml2.FeatureTypeCache;
import org.geotools.gml3.GMLConfiguration;
import org.geotools.xml.PullParser;
import org.opengis.feature.simple.SimpleFeature;
import org.opengis.feature.type.FeatureType;
import org.xml.sax.SAXException;

public class GMLPullParserReader {

/**
 * Does not cache the feature type, allowing each feature to have its
own
 */
private static final class FeatureTypeCacheNone extends
FeatureTypeCache {
@Override
public void put(FeatureType type) {
// no op
}
}

public static void main(String[] args) throws XMLStreamException,
IOException, SAXException {
pullParse(new File("/tmp/GetFeatureResponse1.xml"));
pullParse(new File("/tmp/GetFeatureResponse2.xml"));
}

private static void pullParse(File input)
throws FileNotFoundException, XMLStreamException, IOException,
SAXException {
GMLConfiguration configuration = new GMLConfiguration();
PullParser parser = new PullParser(configuration, new
FileInputStream(input), SimpleFeature.class);
parser.setContextCustomizer(context -> {
Object instance =
context.getComponentInstanceOfType(FeatureTypeCache.class);
context.unregisterComponentByInstance(instance);
context.registerComponentInstance(new FeatureTypeCacheNone());
});
SimpleFeature f = null;
while((f = (SimpleFeature)parser.parse()) != null) {
System.out.println(f.getFeatureType());
}
}
}

---

The two collections have features in different orders, resulting in
different feature types in a normal
parse... but with this trick, no problem, each feature has its own full
feature type instead.

Now, extending this code one could at the same time accumulate the features
in a list,
determine an all encompassing feature type, and then return a
SimpleFeatureCollection.
And I wanted to do all this in a method in the GML facade, to hide the
details.

Thinking about it, it's not that I really need to use a pull parser, I
could use the normal one too,
provided that the feature collection binding stops using a
DefaultFeatureCollection, and
uses a new "GMLFeatureCollection" that does not complain about mixed
feature types :-p

Hope this clarifies things a bit

Cheers
Andrea

-- 
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

Re: [Geotools-devel] Improving parsing GML files without a reference to the schema

[Justin Deoliveira]

On Sun, Jan 31, 2016 at 2:37 AM Andrea Aime 
wrote:

> On Fri, Jan 29, 2016 at 4:00 PM, Justin Deoliveira 
> wrote:
>
>> These could be added as new methods to the GML facade class:
>>> SimpleFeatureType GML.decodeSchema(InputStream in)
>>> SimpleFeatureCollection GML.decodeFeatureCollection(InputStream in)
>>>
>>> I wonder if you could handle both the scan only single feature vs scan
>> full feature collection with a single additional integer argument. The
>> argument would be the number of features to “pre-scan” to compile the
>> schema. This would allow for a bit more control for larger GML collections
>> where you might not want to scan the whole collection but you want to scan
>> more than just the first. Just a thought.
>>
>
> I'm a bit perplexed... like, it seems to me the two significant values
> would be "1", aka "no null values, my collection is fully uniform" and "0",
> aka "no clue, scan till the end", when you don't know
> where the "odd one out" would be.
> I do realize that most of the time scanning the first few features would
> give you the final schema, but there is no reliability regarding the
> number of features where this happens, the odd case out being exactly the
> one where the attribute shows only in the last
> features of the series (which happens if you do a "order by myAtt desc" in
> a sql query, the null values are packed at
> the beginning of the series).
>
> My thought was that for larger GML collections you may want to lookahead
more than one feature, but you may not want to pay the cost of scanning all
features. So the values would be:

< 1 - scan everything
= 1 - scan just the first
> 1 - scan the first n features

If you don’t think that makes sense that is fine, was just an idea.

So, let me show you what I did in my little experiment, this will also
> explain why I was talking about pull
> parsing :-)
>
> My starting point is a desire to parse a feature collection in GML, and
> get back a SimpleFeatureCollection
> (streaming is not a requirement here). So I started using a normal Parser,
> which gives me back the SimpleFeatureCollection.
>
> However, noticed that the FeatureTypeCache was caching the type of the
> first feature... I then injected in the
> pico context a subclass that would not cache, and then
> DefaultFeatureCollection would start complaining in
> the logs that the features being inserted into it are not a match for its
> feature type (determined from
> the first feature).
>
> So ok, I decided to give the pull parser a try, that does not use a
> collection... here is the result:
>
> ---
>
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.FileNotFoundException;
> import java.io.IOException;
>
> import javax.xml.stream.XMLStreamException;
>
> import org.geotools.gml2.FeatureTypeCache;
> import org.geotools.gml3.GMLConfiguration;
> import org.geotools.xml.PullParser;
> import org.opengis.feature.simple.SimpleFeature;
> import org.opengis.feature.type.FeatureType;
> import org.xml.sax.SAXException;
>
> public class GMLPullParserReader {
>
> /**
>  * Does not cache the feature type, allowing each feature to have its
> own
>  */
> private static final class FeatureTypeCacheNone extends
> FeatureTypeCache {
> @Override
> public void put(FeatureType type) {
> // no op
> }
> }
>
> public static void main(String[] args) throws XMLStreamException,
> IOException, SAXException {
> pullParse(new File("/tmp/GetFeatureResponse1.xml"));
> pullParse(new File("/tmp/GetFeatureResponse2.xml"));
> }
>
> private static void pullParse(File input)
> throws FileNotFoundException, XMLStreamException, IOException,
> SAXException {
> GMLConfiguration configuration = new GMLConfiguration();
> PullParser parser = new PullParser(configuration, new
> FileInputStream(input), SimpleFeature.class);
> parser.setContextCustomizer(context -> {
> Object instance =
> context.getComponentInstanceOfType(FeatureTypeCache.class);
> context.unregisterComponentByInstance(instance);
> context.registerComponentInstance(new FeatureTypeCacheNone());
> });
> SimpleFeature f = null;
> while((f = (SimpleFeature)parser.parse()) != null) {
> System.out.println(f.getFeatureType());
> }
> }
> }
>
> ---
>
> The two collections have features in different orders, resulting in
> different feature types in a normal
> parse... but with this trick, no problem, each feature has its own full
> feature type instead.
>
> Now, extending this code one could at the same time accumulate the
> features in a list,
> determine an all encompassing feature type, and then return a
> SimpleFeatureCollection.
> And I wanted to do all this in a method in the GML facade, to hide the
> details.
>
> Thinking 

Re: [Geotools-devel] Improving parsing GML files without a reference to the schema

[Justin Deoliveira]

Hey Andrea,

Some comments/questions inline.

On Fri, Jan 29, 2016 at 4:44 AM Andrea Aime 
wrote:

> Hi,
> I'm looking into improving our ability to parse GML files whose reference
> to the schema is invalid or unreachable, in other words, not usable.
>
> Right now the parser generates a feature collection by reflecting the
> schema
> out of the first feature, which causes issues some cases, like
> missing elements in the first feature (because they are null), which will
> be then not part of the schema, and will be pruned from any subsequent
> feature too.
>
> My first idea would be to mimic what we have in the GeoJSON module and
> allow the client to perform two parses, one that would determine the best
> feature type by scrolling over the GML (see
> FeatureJSON.readFeatureCollectionSchema),
> and a second one that can take the target feature type as a hint (see
> FeatureJSON.setFeatureType).
>
> These could be added as new methods to the GML facade class:
> SimpleFeatureType GML.decodeSchema(InputStream in)
> SimpleFeatureCollection GML.decodeFeatureCollection(InputStream in)
>
> I wonder if you could handle both the scan only single feature vs scan
full feature collection with a single additional integer argument. The
argument would be the number of features to “pre-scan” to compile the
schema. This would allow for a bit more control for larger GML collections
where you might not want to scan the whole collection but you want to scan
more than just the first. Just a thought.


> Internally I'd pass a custom FeatureTypeCache that is not caching anything
> in the first
> case, allowing each feature to have its own natural feature type, and the
> second one
> to prime the cache with the target feature type.
>
> However, I was thinking that the same could be done in a single call,
> since we'd
> be getting a in memory feature collection anyways, so we can really just
> figure
> out the best fitting feature type, and then decorate the collection with a
> retyping one that will be returned. This would be best done using a
> PullParser,
> as we could control how the collection gets build (otherwise we end with a
> DefaultFeatureCollection that would spam the logs complaining the feature
> type
> of the last feature added is not the same as the collection one).
>
> I don’t quite follow this part… the features are all going to be pull into
memory?


> This would however incur in a bit of extra cost... but probably negligible
> comparedf
> to the GML parsing itself... at the same time, the PullParser  is not as
> tested as the non pull one.
>
> So, we have two solutions, one safe but slower, based on two methods,
> using the normal
> parser, and doing two scans, one faster but a litter bit more untested,
> using
> the PullParser.
>
> Which avenue would be the preferred one? Mind, I'd also need to backport
> this little
> new feature
>
> Cheers
> Andrea
>
> --
> ==
> GeoServer Professional Services from the experts! Visit
> http://goo.gl/it488V for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39  339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*
>
> Le informazioni contenute in questo messaggio di posta elettronica e/o
> nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
> loro utilizzo è consentito esclusivamente al destinatario del messaggio,
> per le finalità indicate nel messaggio stesso. Qualora riceviate questo
> messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
> darcene notizia via e-mail e di procedere alla distruzione del messaggio
> stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
> divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
> utilizzarlo per finalità diverse, costituisce comportamento contrario ai
> principi dettati dal D.Lgs. 196/2003.
>
>
>
> The information in this message and/or attachments, is intended solely for
> the attention and use of the named addressee(s) and may be confidential or
> proprietary in nature or covered by the provisions of privacy act
> (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
> Code).Any use not in accord with its purpose, any disclosure, reproduction,
> copying, distribution, or either dissemination, either whole or partial, is
> strictly forbidden except previous formal approval of the named
> addressee(s). If you are not the intended recipient, please contact
> immediately the sender by telephone, fax or e-mail and delete the
> information in this message that has been received in error. The sender
> does not give any warranty or accept liability as the content, accuracy or
> completeness of sent messages and accepts no responsibility  for changes
> made after they were sent or