[Geoserver-devel] Revisiting output formats for easy UI plugging

Andrea_Aime3 · April 8, 2009, 5:13pm

Hi,
so doing the map preview I stumbled upon a few hiccups
of how the output formats are handled.
In particular, each output format has not one, but a
number of possible output formats names:

- GetMapProducer.getOutputFormatNames()
- WFSGetFeatureOutputFormat.getOutputFormats()

Capabilities documents build on top of this list directly,
but there are a few hiccups: some output formats list three
different synonyms for the same result, that is not good for
UI generation at all...
For example, we have GeoRSS list the following:
* application/rss+xml
* rss
* application/rss xml (yeah, without the +)
And GML ones list something like:
* gml3
* text/xml; subtype=gml/3.1.1

For the map preview I need just one. But there is also
the opposite, output formats that list more because
they can do more than one, this is the case of the
image output formats, where one class is usually
able to produce both the 24 and 8 bit outputs:
* "image/geotiff"
* "image/geotiff8"
(whilst the output mime type is just image/tiff since
there is no actual geotiff MIME)

So what I'd need is a list of valid output format
name, but without duplicates, if there are multiple
names I'm fine, but I need them to be doing different
things.

Afaik the output of getOutputFormats() is used for
matching the output format in the dispatcher, and
for that case the availability of synonims is good.

It seems we need a new call for a distilled list?
Or adding a boolean flag to the existing one?
Like:
getOutputFormat(synonims)

Opinions?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · April 8, 2009, 5:39pm

I see two possible solutions:

1) we add the method you are proposing. However I see a possible problem with this (i might be understanding). The problem is that isn't there loss of information in the cases there the output format actually does multiple different formats, rather just provide synonims. For instance with geotiff and geotiff8, if you map this two a single string how do you know how to do the reverse mapping.

Or... are you prosing that getOutputFormat return a list... and based on the flag that list might contain synonyms or not.

2) the second way to solve this would be to come up with some sort of mapping extension point, that could map mime types or output format names to human readable titles. Something like:

class OutputFormatTitle {

String getTitle( String outputFormat );
}

With this extension point the ui could walk through and build up the list of titles (factoring out synonyms since synonyms would map to the same title string).

While I think the first would be easier to implement it kind of seems a bit hackish... the second I think is a bit cleaner and means we don't have to muck up any of the existing output format code.

Andrea Aime wrote:

Hi,
so doing the map preview I stumbled upon a few hiccups
of how the output formats are handled.
In particular, each output format has not one, but a
number of possible output formats names:

- GetMapProducer.getOutputFormatNames()
- WFSGetFeatureOutputFormat.getOutputFormats()

Capabilities documents build on top of this list directly,
but there are a few hiccups: some output formats list three
different synonyms for the same result, that is not good for
UI generation at all...
For example, we have GeoRSS list the following:
* application/rss+xml
* rss
* application/rss xml (yeah, without the +)
And GML ones list something like:
* gml3
* text/xml; subtype=gml/3.1.1

For the map preview I need just one. But there is also
the opposite, output formats that list more because
they can do more than one, this is the case of the
image output formats, where one class is usually
able to produce both the 24 and 8 bit outputs:
* "image/geotiff"
* "image/geotiff8"
(whilst the output mime type is just image/tiff since
there is no actual geotiff MIME)

So what I'd need is a list of valid output format
name, but without duplicates, if there are multiple
names I'm fine, but I need them to be doing different
things.

Afaik the output of getOutputFormats() is used for
matching the output format in the dispatcher, and
for that case the availability of synonims is good.

It seems we need a new call for a distilled list?
Or adding a boolean flag to the existing one?
Like:
getOutputFormat(synonims)

Opinions?
Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Andrea_Aime3 · April 8, 2009, 7:26pm

Justin Deoliveira ha scritto:

I see two possible solutions:

1) we add the method you are proposing. However I see a possible problem with this (i might be understanding). The problem is that isn't there loss of information in the cases there the output format actually does multiple different formats, rather just provide synonims. For instance with geotiff and geotiff8, if you map this two a single string how do you know how to do the reverse mapping.

Or... are you prosing that getOutputFormat return a list... and based on the flag that list might contain synonyms or not.

Yep, this one. Returning a list, without synomyms if the boolean
parameter is up.

2) the second way to solve this would be to come up with some sort of mapping extension point, that could map mime types or output format names to human readable titles. Something like:

class OutputFormatTitle {

String getTitle( String outputFormat );
}

With this extension point the ui could walk through and build up the list of titles (factoring out synonyms since synonyms would map to the same title string).

While I think the first would be easier to implement it kind of seems a bit hackish... the second I think is a bit cleaner and means we don't have to muck up any of the existing output format code.

The second is basically there already, the mapping function is
looking up the title on the i18n subsystem using the mime as
a key (works, you have to escape spaces and equals in the key)
but I did not like it much. To me having the synonyms in the
output formats seemed the hack instead: the capabilities
are sending out this duplicated blob of formats as well,
and a smart(ish) client can present that very list to a user.
Here is what comes out of the WMS caps (on 1.7.3):

<Format>image/png</Format>
<Format>application/atom xml</Format>
<Format>application/atom+xml</Format>
<Format>application/openlayers</Format>
<Format>application/pdf</Format>
<Format>application/rss xml</Format>
<Format>application/rss+xml</Format>
<Format>application/vnd.google-earth.kml</Format>
<Format>application/vnd.google-earth.kml xml</Format>
<Format>application/vnd.google-earth.kml+xml</Format>
<Format>application/vnd.google-earth.kmz</Format>
<Format>application/vnd.google-earth.kmz xml</Format>
<Format>application/vnd.google-earth.kmz+xml</Format>
<Format>atom</Format>
<Format>image/geotiff</Format>
<Format>image/geotiff8</Format>
<Format>image/gif</Format>
<Format>image/jpeg</Format>
<Format>image/png8</Format>
<Format>image/svg</Format>
<Format>image/svg xml</Format>
<Format>image/svg+xml</Format>
<Format>image/tiff</Format>
<Format>image/tiff8</Format>
<Format>kml</Format>
<Format>kmz</Format>
<Format>openlayers</Format>
<Format>rss</Format>

As you can see, rss is expressed 3 times, kml a whopping 6
times, and so on.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Gabriel_Roldan2 · April 8, 2009, 7:30pm

I like the second option more too.

Gabriel
Justin Deoliveira wrote:

I see two possible solutions:

1) we add the method you are proposing. However I see a possible problem with this (i might be understanding). The problem is that isn't there loss of information in the cases there the output format actually does multiple different formats, rather just provide synonims. For instance with geotiff and geotiff8, if you map this two a single string how do you know how to do the reverse mapping.

Or... are you prosing that getOutputFormat return a list... and based on the flag that list might contain synonyms or not.

2) the second way to solve this would be to come up with some sort of mapping extension point, that could map mime types or output format names to human readable titles. Something like:

class OutputFormatTitle {

String getTitle( String outputFormat );
}

With this extension point the ui could walk through and build up the list of titles (factoring out synonyms since synonyms would map to the same title string).

While I think the first would be easier to implement it kind of seems a bit hackish... the second I think is a bit cleaner and means we don't have to muck up any of the existing output format code.

Andrea Aime wrote:

Hi,
so doing the map preview I stumbled upon a few hiccups
of how the output formats are handled.
In particular, each output format has not one, but a
number of possible output formats names:

- GetMapProducer.getOutputFormatNames()
- WFSGetFeatureOutputFormat.getOutputFormats()

Capabilities documents build on top of this list directly,
but there are a few hiccups: some output formats list three
different synonyms for the same result, that is not good for
UI generation at all...
For example, we have GeoRSS list the following:
* application/rss+xml
* rss
* application/rss xml (yeah, without the +)
And GML ones list something like:
* gml3
* text/xml; subtype=gml/3.1.1

For the map preview I need just one. But there is also
the opposite, output formats that list more because
they can do more than one, this is the case of the
image output formats, where one class is usually
able to produce both the 24 and 8 bit outputs:
* "image/geotiff"
* "image/geotiff8"
(whilst the output mime type is just image/tiff since
there is no actual geotiff MIME)

So what I'd need is a list of valid output format
name, but without duplicates, if there are multiple
names I'm fine, but I need them to be doing different
things.

Afaik the output of getOutputFormats() is used for
matching the output format in the dispatcher, and
for that case the availability of synonims is good.

It seems we need a new call for a distilled list?
Or adding a boolean flag to the existing one?
Like:
getOutputFormat(synonims)

Opinions?
Cheers
Andrea

Gabriel_Roldan2 · April 8, 2009, 7:47pm

Andrea Aime wrote:

Justin Deoliveira ha scritto:

I see two possible solutions:

1) we add the method you are proposing. However I see a possible problem with this (i might be understanding). The problem is that isn't there loss of information in the cases there the output format actually does multiple different formats, rather just provide synonims. For instance with geotiff and geotiff8, if you map this two a single string how do you know how to do the reverse mapping.

Or... are you prosing that getOutputFormat return a list... and based on the flag that list might contain synonyms or not.

Yep, this one. Returning a list, without synomyms if the boolean
parameter is up.

2) the second way to solve this would be to come up with some sort of mapping extension point, that could map mime types or output format names to human readable titles. Something like:

class OutputFormatTitle {

String getTitle( String outputFormat );
}

With this extension point the ui could walk through and build up the list of titles (factoring out synonyms since synonyms would map to the same title string).

While I think the first would be easier to implement it kind of seems a bit hackish... the second I think is a bit cleaner and means we don't have to muck up any of the existing output format code.

The second is basically there already, the mapping function is
looking up the title on the i18n subsystem using the mime as
a key (works, you have to escape spaces and equals in the key)
but I did not like it much. To me having the synonyms in the
output formats seemed the hack instead: the capabilities
are sending out this duplicated blob of formats as well,
and a smart(ish) client can present that very list to a user.
Here is what comes out of the WMS caps (on 1.7.3):

I would prefer a shorter list too, but at the time aliases were needed because there were already a lot of code using them, but they weren't advertised in the capabilities. That is, everybody wanted to use "openlayers" or "atom" in the requests, but those were just not in the capabilities, so it was magic.
Moreover, the ones without the "+" where required for those sending a request from a web browser that does not escape the spaces in the URL.
Hence the aliases, to stop magic.
This issue is somewhat related <http://jira.codehaus.org/browse/GEOS-2124>

some things like image/geotiff, image/geotiff8, image/png, image/png8 etc should imho be better advertised as a parametrized MIME type, eg, image/png;color-depth=8 or image/tiff;geotiff=true

comments?

<Format>image/png</Format>
<Format>application/atom xml</Format>
<Format>application/atom+xml</Format>
<Format>application/openlayers</Format>
<Format>application/pdf</Format>
<Format>application/rss xml</Format>
<Format>application/rss+xml</Format>
<Format>application/vnd.google-earth.kml</Format>
<Format>application/vnd.google-earth.kml xml</Format>
<Format>application/vnd.google-earth.kml+xml</Format>
<Format>application/vnd.google-earth.kmz</Format>
<Format>application/vnd.google-earth.kmz xml</Format>
<Format>application/vnd.google-earth.kmz+xml</Format>
<Format>atom</Format>
<Format>image/geotiff</Format>
<Format>image/geotiff8</Format>
<Format>image/gif</Format>
<Format>image/jpeg</Format>
<Format>image/png8</Format>
<Format>image/svg</Format>
<Format>image/svg xml</Format>
<Format>image/svg+xml</Format>
<Format>image/tiff</Format>
<Format>image/tiff8</Format>
<Format>kml</Format>
<Format>kmz</Format>
<Format>openlayers</Format>
<Format>rss</Format>

As you can see, rss is expressed 3 times, kml a whopping 6
times, and so on.

Cheers
Andrea

Andrea_Aime3 · April 9, 2009, 8:16am

Gabriel Roldan ha scritto:

I would prefer a shorter list too, but at the time aliases were needed because there were already a lot of code using them, but they weren't advertised in the capabilities. That is, everybody wanted to use "openlayers" or "atom" in the requests, but those were just not in the capabilities, so it was magic.

Uh? How was this working? The caps had a hard coded list of output
formats?

Anyways, I did not ask for the convenience synonyms to be removed,
more that I'd like to have a way to filter them out for UI and
capabilities building cases. But keep them in for

Moreover, the ones without the "+" where required for those sending a request from a web browser that does not escape the spaces in the URL.
Hence the aliases, to stop magic.
This issue is somewhat related <http://jira.codehaus.org/browse/GEOS-2124>

some things like image/geotiff, image/geotiff8, image/png, image/png8 etc should imho be better advertised as a parametrized MIME type, eg, image/png;color-depth=8 or image/tiff;geotiff=true

Yup, I agree. However, this kind of change need to be performed by
adding more synonyms to the mix, otherwise people upgrading will
be screwed by our name changes. image/tiff;geotiff=true becomes the
new advertised format name, but we need to keep image/geotiff around
for backwards compatibility (just stop advertising it).
If we stop advertising the convenience synonyms sooner or later
they will fall out of fashion.

I'm also ok on removing GetMapProducer.getOutputFormat, it does not
even match with the fact that some producers generate more than one
kind of output (png and png8). I still think its multi-result friend,
getOutputFormatNames() should provide us a way to filter out the
synonyms so that we can produce good capabilities document and
good UI without the need to perform mapping and duplicate removal.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.