To whom it may concern,
Hi guys,
- I have to build a Java component that will convert GML (Geography Markup Language) to WKT or WKT and vice-versa. I will have these methods:
-
GMLtoWKT
-
GMLtoWKB
-
WKTtoGML
-
WKBtoGML
-
GMLtoESRIShapefile
-
ESRIShapefiletoGML
-
WKTtoWKB
-
WKBtoWKT
That component has to be alone, a straight converter!
- My component will be used in an OpenGIS Web Service standard. Do you know where I can find a Java Framework to implement my component through the Web Service?
Thank you for your help
Best Regards
Roberto
Fujitsu Consulting for Agriculture Canada
Nice!
1) I have to build a Java component that will convert GML (Geography Markup Language) to WKT or WKT and vice-versa. I will have these methods:
That component has to be alone, a straight converter!
You could implement this as a wrapper on the existing geotool DataStore API - what is interesting is if you are using this for an OWS all your implementations will need to be stream based. This can be *very* hard with GML because GML assumes you know your bounding box *before* you write out the actual content. Hard to do if you only get one pass through the data.
2) My component will be used in an OpenGIS Web Service standard. Do you know where I can find a Java Framework to implement my component through the Web Service?
GeoServer has an Open Web Service layout, and implements WFS and WMS, you should talk to chris holmes the project leader. The application is fairly modular and would have a lot of the boiler plate code (GetCapabilities, WKT Request Parsing etc...) already done.
Jody
At 14:06 14/10/2004 -0700, Jody Garnett wrote:
Nice!
1) I have to build a Java component that will convert GML (Geography Markup Language) to WKT or WKT and vice-versa. I will have these methods:
That component has to be alone, a straight converter!
You could implement this as a wrapper on the existing geotool DataStore API - what is interesting is if you are using this for an OWS all your implementations will need to be stream based. This can be *very* hard with GML because GML assumes you know your bounding box *before* you write out the actual content. Hard to do if you only get one pass through the data.
The Ordinance Survey get round this by using an indocument reference to a geometry which they include towards the end of the GML file. Sneaky, but apparently valid.
James
James Macgill wrote:
At 14:06 14/10/2004 -0700, Jody Garnett wrote:
Nice!
1) I have to build a Java component that will convert GML (Geography Markup Language) to WKT or WKT and vice-versa. I will have these methods:
That component has to be alone, a straight converter!
You could implement this as a wrapper on the existing geotool DataStore API - what is interesting is if you are using this for an OWS all your implementations will need to be stream based. This can be *very* hard with GML because GML assumes you know your bounding box *before* you write out the actual content. Hard to do if you only get one pass through the data.
The Ordinance Survey get round this by using an indocument reference to a geometry which they include towards the end of the GML file. Sneaky, but apparently valid.
Now why didn't I think of that - I wonder if David would go for it
Roberto - geotools has just made a very powerful GML parser (currently supports GML 2.x because the developer David Zwiers is only interested in WFS support). It is a bit tricky extending this to GML3 support because of a lack of classes representing GML3 constructs. But it sounded like you were staying within the bounds of Shapefiles ....
Do you have specific needs with respect to versions?
Jody
On Thu, 2004-10-14 at 15:18, James Macgill wrote:
At 14:06 14/10/2004 -0700, Jody Garnett wrote:
>Nice!
>
>>1) I have to build a Java component that will convert GML (Geography
>>Markup Language) to WKT or WKT and vice-versa. I will have these methods:
>>
>>That component has to be alone, a straight converter!
>You could implement this as a wrapper on the existing geotool DataStore
>API - what is interesting is if you are using this for an OWS all your
>implementations will need to be stream based. This can be *very* hard with
>GML because GML assumes you know your bounding box *before* you write out
>the actual content. Hard to do if you only get one pass through the data.
The Ordinance Survey get round this by using an indocument reference to a
geometry which they include towards the end of the GML file. Sneaky, but
apparently valid.
Yes, but it binds you to in-memory only FeatureCollections if you want
to only parse the stream once ... so I didn't support it. As a side
note, I have not seen this used yet (FME and WFS both use conventional
XML).
David
James
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
At 15:52 14/10/2004 -0700, David Zwiers wrote:
On Thu, 2004-10-14 at 15:18, James Macgill wrote:
> At 14:06 14/10/2004 -0700, Jody Garnett wrote:
> >Nice!
> >
> >>1) I have to build a Java component that will convert GML (Geography
> >>Markup Language) to WKT or WKT and vice-versa. I will have these methods:
> >>
> >>That component has to be alone, a straight converter!
> >You could implement this as a wrapper on the existing geotool DataStore
> >API - what is interesting is if you are using this for an OWS all your
> >implementations will need to be stream based. This can be *very* hard with
> >GML because GML assumes you know your bounding box *before* you write out
> >the actual content. Hard to do if you only get one pass through the data.
>
> The Ordinance Survey get round this by using an indocument reference to a
> geometry which they include towards the end of the GML file. Sneaky, but
> apparently valid.
Yes, but it binds you to in-memory only FeatureCollections if you want
to only parse the stream once ... so I didn't support it. As a side
note, I have not seen this used yet (FME and WFS both use conventional
XML).
Not sure what you mean as they did this specifically to allow for a parse once stream based approach, the bbox is built as the features stream then its stuck at the end of the GML stream. The bbox at the beginning of the stream only holds a reference to the bbox which will be generated once all of the features have been processed.
James
Hi everybody,
as far as I have read in this list, raster support is not yet available
in Geoserver, right?
I have also read that probably the best alternative is to use Geoserver
for the vector data together with MapServer for the raster data. Does
anybody have any experience with this configuration? Does anybody
suggest any other alternative? I would really appreciate if anybody
could give me a couple of hints about how to configure this...
Thanks!
Best regards,
Juan
P.D: By the way, do you have any idea if it is expected to be supported
in future geoserver releases?
Quoting Juan de Castro <jcastro@anonymised.com>:
Hi everybody,
as far as I have read in this list, raster support is not yet
available
in Geoserver, right?
Correct.
I have also read that probably the best alternative is to use
Geoserver
for the vector data together with MapServer for the raster data. Does
anybody have any experience with this configuration? Does anybody
suggest any other alternative? I would really appreciate if anybody
could give me a couple of hints about how to configure this...
Personally no. If anyone does have thoughts on this though it would be
a great thing to add to the wiki for others to use:
http://docs.codehaus.org/display/GEOS/Home
(yes, it's unorganized, we're working on that).
P.D: By the way, do you have any idea if it is expected to be
supported
in future geoserver releases?
Yes, it's one of the top priorities for 1.3, on which we will be
starting work shortly. There's been a good bit of work done in
GeoTools, and it's getting cleaned up now, so should be ready to roll
in relatively soon.
Chris
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on
ITManagersJournal
Use IT products in your business? Tell us what you think of them.
Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find
out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/