Martin wrote: "As for auto-determining input data types, there's two reasons we choose to provide a template containing this and other information - if the input file is empty you still need to know the datatype in order to create a layer - the template made it easier to specify exactly which elements contained attribute values."
Understood. I actually thought about an "empty" GML file. I think I can throw the user a warning message and abort the file import if I encounter this situation. Martin wrote: "You could certainly write code that "guessed" the information contained in the template. In the end internally you'd end up creating a data structure which contains exactly the information in the template. We just didn't take the coding this one step further, due to lack of time and use cases." Understood. Martin wrote: "I agree that the template is a bit complicated - but at least it lets you parse a GML file. You can probably find other tools which does this for you a bit more automatically (OGR maybe?). At the time we wrote this code none of these were available." I don't plan on using another tool. I'm actually writing my own tool. It looks like I have two (2) options to proceed with. I can think about a much simpler input template. Something like this: Attribute Name Attribute DataType numberOfLanes integer surfaceType String dateConstructed Date Or, I can automatically determine the attribute data type for non-empty files. I'm actually dealing with a GML 2 file whose content I already know, so I could write a special parser that already knows what attributes to expect. However, I thought it might benefit others if I could improve a more generic GML 2 parser. Thanks for your comments Martin. The Sunburned Surveyor On Thu, Sep 18, 2008 at 4:24 PM, Martin Davis <[EMAIL PROTECTED]> wrote: > I second Paul's idea about looking at the spec for examples. You need > more gunk than is in your example - welcome to the wonderful world of XML... > > As for auto-determining input data types, there's two reasons we choose > to provide a template containing this and other information > - if the input file is empty you still need to know the datatype in > order to create a layer > - the template made it easier to specify exactly which elements > contained attribute values. > > You could certainly write code that "guessed" the information contained > in the template. In the end internally you'd end up creating a data > structure which contains exactly the information in the template. We > just didn't take the coding this one step further, due to lack of time > and use cases. > > I agree that the template is a bit complicated - but at least it lets > you parse a GML file. You can probably find other tools which does this > for you a bit more automatically (OGR maybe?). At the time we wrote > this code none of these were available. > > Sunburned Surveyor wrote: >> I'm doing some work converting GPX files into "waypoint observations" >> stored in GML 2. I want to be able to read the GML 2 files into >> OpenJUMP. I had a couple of questions that I thought you guys could >> help with: >> >> [1] I'm trying to figure out what the "header" of a GML 2 file should >> look like. I'll be buggered if I can't find a good GML 2 sample file >> on the web. Is this what a GM you2 file should look like?: >> >> <gml> >> <featureCollection> >> <someFeature> >> <someAttribute>Some Attribute Value</someAttribute> >> <someOtherAttribute>Some Other Attribute Value</someOtherAttribute> >> </someFeature> >> </featureCollection> >> </gml> >> >> [2] I know that OpenJUMP currently requires the use of an input >> template to read GML. I was wondering if it might be possible to >> automatically determine the attribute data type >> (String/Date/Integer/Double) automatically based on the first >> attribute values encountered in the file. This would eliminate the >> need for an input template and would make it easier to import GML 2 >> files. Any thoughts on this? >> >> The Sunburned Surveyor >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> 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 the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
