search

opengeospatial / geotiff

18 stars 9 forks source link

Media (MIME) type for GeoTIFF #34

Closed m-mohr closed 2 years ago

m-mohr commented 5 years ago

In metadata and other use-cases, there is a need to specify of which type a file is to allow clients to handle them appropriately. Software implementors came up with different media types to describe GeoTIFFs as a special form of TIFFs:

There are probably even more invented media types out there. I think there should be a single media type and it should be discussed already what OGC is heading for to lead implementors in one direction.

Another issue to take into consideration: How to handle sub types like cloud optimized geotiffs? Should that be image/cogeo+tiff or image/cog+geotiff or ...?

EmDevys commented 5 years ago

1- First of all, let's remember that GeoTIFF specification (as of https://trac.osgeo.org/geotiff/ = http://geotiff.maptools.org/spec/geotiffhome.html) is (or was) agnostic of MIME type. Of course nowadays, it seems of interest to provide guidance / recommendation (or possibly requirement) on MIME type to be used for handling GeoTIFF data. 2- MIME or media type, being a format identifier on internet, and a GeoTIFF file being a TIFF format file (using GeoTIFF extension for Geo tags), the MIME type should basically be image/tiff, according to RFC 3302 (see also http://www.iana.org/assignments/media-types/media-types.xhtml) 3- Another input of interest is how GDAL documents the MIME type for GeoTIFF files. gdalinfo --format GTIFF command gives the following result for MIME type: Mime Type: image/tiff 4- 2 other references of interest in the OGC are:

In conclusion, as for rfc3302 MIME type is image, and subtype is tiff, I would recommend to add the recommendation to use the image/tiff MIME type when necessary, in accordance with IANA, and OGC GMLCOV GeoTIFF extension requirement.

m-mohr commented 5 years ago

Theoretically, your points may all be valid, but practically there is a need from many developers to know in advance whether a file is a Tiff or a subformat such as GeoTiff or cloud-optimized GeoTiffs. For example, you don't want to download megabytes of data just to realize that you can't display the non-GeoTiff file in your map. GeoJSON and JSON are doing similar things for good reasons so I am wondering why we can't just come up with image/geo+tiff for example. This is completely valid and could be registered with IANA. So I'd vote for this.

EmDevys commented 5 years ago

I understand your point. However once again, the existing GeoTIFF standard is agnostic of MIME type, and nothing in the resulting TIFF/GeoTIFF file is carrying the MIME type. The only way to discover in a TIFF file that it is carrying GeoTIFF information (and tags) is to discover a TIFF Tag GeoKeyDirectoryTag (34735) ! In addition to this, the existing GMLCOV GeoTIFF extension (OGC 12-100r1) specified a MIME identifier: image/tiff. Therefore, if we wish to submit a proposal to IANA as OGC for identification of sub MIME types of TIFF such as GeoTIFF or cloud-optimized GeoTiff (that might be used in the Coverage encapsulation of TIFF/GeoTIFF files - and not in the TIFF/GeoTIFF tags as is), we should first and foremost agree in the OGC ecosystem for GeoTIFF related standards (GeoTIFF in some close future, GMLCOV/CIS-GeoTIFF encoding, WPS) on some harmonized proposal. This issue is left open for discussion, till we may reach a consensus on its resolution. My humble opinion is that TIFF/GeoTIFF tags can presently do nothing to identify that a TIFF file is GeoTIFF on basis of MIME type. The only existing method for solving this is to identify the TIFF Tag GeoKeyDirectoryTag (34735).

EmDevys commented 5 years ago

In addition to my previous comment, you may check https://www.awaresystems.be/imaging/tiff.html which provides an up-to-date register of registered TIFF tags (including GeoTIFF ones). And check that MIME type information is not available in Baseline, Extensiona nd Private TIFF tags

m-mohr commented 5 years ago

The GeoTIff shouldn't carry the media type, but still it would be beneficial to have guidance on a GeoTiff media type. Otherwise in practical use the developers will still come up with proprietary media types, several standards did so (STAC, openEO, even OGC WPS 1.0) and many software as well. So if you'd come up with a usable standard then you need to come up with a separate media type. All your points are valid, but are not very helpful in practice as implementations usually don't want to parse files in advance to check for their type. It's very much the same as for JSON and GeoJSON, which have separate media types.

EmDevys commented 5 years ago

This guidance on MIME type for GeoTIFF file is to be discussed transversely with other OGC SWGs, such as WCS.SWG (using the plain image/tiff) for GMLCOV GeoTIFF extension, and probably WPS. Should the team and SWG have a motion to the TC?

EmDevys commented 5 years ago

As all encodings standard inside the OGC, there should be a recommendation on MIME type (though this is - of course - not addressed by GeoTIFF 1.0. In this draft 1.1 I propose the folliwing text: A GeoTIFF file is a TIFF file. It is common to use the tiff MIME type, image/tiff according to [RFC3302]. OGC GMLCOV GeoTIFF extension (OGC 12-100r1) specifies image/tiff as MIME identifier (cf. Requirement #5). The recommendation for a specific MIME type such as image/tiff+geo, or image/tiff-geo is under consideration in this revision, and should be discussed within the OGC and the imagery communities. To be further discussed and agreed, coordination with TC/OAB is wanted.

m-mohr commented 5 years ago

image/tiff+geo is not IANA compliant, correct would be image/geo+tiff. See RFC6838 for more information. A prominent example to further prove my point is application/geo+json.

Again, to be able to easily identify GeoTiff files I strongly support a media type different to image/tiff, my favorite being image/geo+tiff. It makes implementations so much easier in many cases.

max-martinez commented 5 years ago

Extrapolating from the "prominent example", you might want to consider that image/geo+tiff means "give me/I offer a GeoTIFF in WGS 84", and continue to use image/tiff for more general GeoTIFF images. It's my understanding that application/geo+json only applies to GeoJSON 4 which restricts coordinates to be in WGS 84. This seems to have been motivated by interoperability issues (intended targets of the standardization commonly did not have access to CRS definition databases and reprojection engines).

"For example, you don't want to download megabytes of data just to realize that you can't display the non-GeoTiff file in your map"

Yes, and the same thing can happen, albeit less frequently, if your client can't understand the GeoKeys for whatever reason (not set up to handle custom entries, not up to date with some of the EPSG references, etc.)

thareUSGS commented 5 years ago

image/geo+tiff means "give me/I offer a GeoTIFF in WGS 84"

I hope that never happens. I consider GeoJSON's lock into WGS84 as a major (and unnecessary) flaw in the spec. I understand their reasoning and intent, but the lock-in seems crazy for the near-future use-cases (as WGS84 will be replaced). A recommendation (best practice) to use WGS84 is fine, but please allow flexibility any spatial standard. And the use of decimal degrees simply doesn't work in so many use-cases (not to mention locking a format on Earth). BTW, as shown here (https://metacpan.org/pod/Geo::JSON::CRS) there are efforts to support CRSs in GeoJSON. Lastly, besides my need to support the planetary domain, there have been papers out warning about a single assumed use-case for WGS84 (note there are 6+ variations of WGS84 too).

max-martinez commented 5 years ago

And image/tiff does not work in the cases you describe because

Certainly it isn't the "For example, you don't want to download megabytes of data just to realize that you can't display the non-GeoTiff file in your map" rationale when you are talking about non-earth images (since the vast majority of image/geo+tiff images, if that comes to mean tiff with geokeys, would presumably not be usefully displayable with your images of Ganymede).

I'm asking for the compelling use case for why image/tiff doesn't work because I don't know what it is not because I think it doesn't exist. You and m-mohr seem to have a better sense for what that is and I want to understand that a little better. Can you clarify?

m-mohr commented 5 years ago

image/geo+tiff means "give me/I offer a GeoTIFF in WGS 84"

That is not a good idea, I agree with @thareUSGS here. Regarding CRS I'd go the way charsets are implemented for text documents on the web. For HTML it would be text/html;charset=ISO-8859-1 and for GeoTiff it could be image/geo+tiff;crs=WGS84 or anything similar.

I'm asking for the compelling use case for why image/tiff doesn't work because I don't know what it is not because I think it doesn't exist. You and m-mohr seem to have a better sense for what that is and I want to understand that a little better. Can you clarify?

For us it's simply: We are creating imagery catalogs and would like to indicate whether TIFF files can be shown on a web map or not. See also: https://github.com/radiantearth/stac-spec/issues/251 and https://github.com/radiantearth/stac-spec/issues/54

There must be a reason why there are so many proprietary GeoTiff media types out there. There are people who need it and I don't know why we should limit to image/tiff if it's easy to just give it a separate sub-type such as image/geo+tiff. What's the reason for simply having this (or another) sub-type? It would prevent devs from inventing their own media types. And I certainly don't understand this argument:

However once again, the existing GeoTIFF standard is agnostic of MIME type, and nothing in the resulting TIFF/GeoTIFF file is carrying the MIME type. The only way to discover in a TIFF file that it is carrying GeoTIFF information (and tags) is to discover a TIFF Tag GeoKeyDirectoryTag (34735) !

I don't know any file format that actually carries a media type. That's not how media types work. They are added by servers or clients for communication based on file contents or extensions or other sources, for example the GeoKeyDirectoryTag. It's the same for GeoJSON, that doesn't carry the media type itself. It's simply added whenever useful to HTTP requests/responses etc.

max-martinez commented 5 years ago

There must be a reason why there are so many proprietary GeoTiff media types out there.

I'm not sure this type of argument is going to get you very far.

Never-the-less, I am sympathetic to your struggles. The push back you might be receiving is that on the face of things, your suggestion has a strange smell given that a media type is meant to convey the nature (image) and format (tiff) of the dataset. These aspects are covered fully for GeoTIFF by image/tiff. You are trying to convey something more about the content. You feel that there is something special and critical about georeferencing for geospatial data. Maybe you're right. Not sure.

So I suppose you are arguing that TIFF is so flexible in its specification that you need to use it as a structured type name suffix to indicate the specialized schema extension that represents geospatial imagery, similar to application/geo+json (whose specification you disagree with) and image/svg+xml. Perhaps that argument can win the day. Again, not sure.

We are creating imagery catalogs and would like to indicate whether TIFF files can be shown on a web map or not

OK, I'm strangely envisioning a catalog of images indicated by URL whose only other metadata is a flag indicating whether or not it is displayable on a map. No bounding box. No pixel type information. No band count. That's weird to me.

Anyhow, I caution you that you have to be more deliberate to achieve your desired outcome. A ModelTiePointTag containing 0, 0, 0, a ModelPixelScaleTag containing 1,-1, 0 and a GTModelTypeGeoKey value of 0 = undefined or unknown is perfectly valid GeoTIFF. And that would not be an unreasonable way for someone to associate geokeys with an unreferenced geospatial image if they thought that advertisement of image/geo+tiff was a good way to indicate their geospatial image holdings (i.e., these TIFFs are not cute pictures of cats).

m-mohr commented 5 years ago

your suggestion has a strange smell given that a media type is meant to convey the nature (image) and format (tiff) of the dataset.

Why does it have a strange smell to do what is common sense for formats such as XML, JSON and others? They all have type/something+format media types. Again, I have not figured out why it seems problematic to have a separate type instead of image/tiff?

So I suppose you are arguing that TIFF is so flexible in its specification that you need to use it as a structured type name suffix to indicate the specialized schema extension that represents geospatial imagery

Whatever it will be, may not be a suffix, but could also be a parameter. So if you are really strongly want to stay with image/tiff, then standardize a parameter so that you can separate Tiff from GeoTiff (OGC WPS once had image/tiff;subtype=geotiff). I feel that if you have a international specification for a file format, you should also have a media type that identifies files that comply to this specification.

similar to application/geo+json (whose specification you disagree with)

Where did you get this from? I don't disagree fully with GeoJSON, just think it has some flaws, but still works for most use cases quite well.

OK, I'm strangely envisioning a catalog of images indicated by URL whose only other metadata is a flag indicating whether or not it is displayable on a map. No bounding box. No pixel type information. No band count. That's weird to me.

I have never said that, too. Just look at a STAC catalog [json, html] / STAC Item [json, html] and/or the discussion I linked to above, so that you don't need to envision one yourself.

cmheazel commented 5 years ago

FYI: The OGC Naming Authority review of the GeoTIFF spec included the comment "Section 8 lists some potential media types for GeoTIFF. application/geotiff should also be considered alongside image/tiff+geo, or image/tiff-geo"

cmheazel commented 5 years ago

Since this will be an OGC registered Media Type, we should follow previous OGC practice. Looking at the IANA registry, the pattern is {schema}+{encoding} (ex. GML is gml+xml). So GeoTIFF would be image/geo+tiff.

max-martinez commented 5 years ago

Where did you get this from?

thareUSGS apparently ("I consider GeoJSON's lock into WGS84 as a major (and unnecessary) flaw in the spec."). My apologies for attributing it to you.

I have never said that, too

Agreed. I was telling you what I was envisioning, not what you said. Thank you for the links, though, they were very helpful. I see now that your motivation is to use the mime type in communicating with your clients as a provider of a STAC catalog (not sure if I'm phrasing that right), not necessarily as something to be relied upon from the servers the implementation filling your catalog might be crawling. It is clearer now to me what you are trying to do.

So although the image/geo+tiff mime type cmheazel indicates you should soon have at your disposal does NOT necessarily mean

but merely

the other metadata you presumably collect upon harvest will help you protect your clients from accessing an asset that can't be displayed on a web map.

max-martinez commented 5 years ago

Since this will be an OGC registered Media Type, we should follow previous OGC practice. Looking at the IANA registry, the pattern is {schema}+{encoding} (ex. GML is gml+xml). So GeoTIFF would be image/geo+tiff.

A couple of observations on this for consideration. Presumably the gml+xml pattern works because, e.g., a json encoding of gml is conceivable (I think that was explored in ows-9 maybe...not sure what's happening now). In the case of GeoTIFF as image/geo+tiff, what does the "geo" schema encompass? It seems like it would have to encompass: a collection of one or more image file directories (and their image data) which include the geospatial tags described by the GeoTIFF spec (see requirement 1.1). Not only is that unlikely to have another encoding beyond TIFF, it conflicts with a subtype of an already registered MIME type (application/geo+json) where it refers to an entirely different schema. Certainly many IANA registered types that use the structured type name suffix may never have another encoding and I don't know that there is any explicit rule against using the same subtype name under two different types to mean different things. But DICOM seems to be a more orderly example in this regard (image/dicom-rle, application/dicom-json, etc.) I'll also note that there is an existing (non-OGC) precedent in the image type (image/tiff-fx) which would make much more sense for, e.g., cog (image/tiff-cog) and maybe for plain old GeoTIFF (image/tiff-geo). Not sure.

In any case, if continuing down the image/geo+tiff road, the OGC may wish to consider a slightly different subtype than "geo" since it is already in use under another type and refers to an entirely different schema. Might be confusing.

m-mohr commented 5 years ago

I don't think this is an issue or confusing. The subtypes don't need to be unique as they are bound to the type, i.e. tiff / json.

max-martinez commented 5 years ago

Fair enough. One more thought experiment: if people had wanted the GMLJP2 spec to specify/register a MIME type for a similar purpose, would it have been image/gml+jp2? Does that imply that the OGC's precedent, if fully spelled out, should be viewed like "{schema (used to make the structured syntax specified in the suffix geospatial)}+{encoding}"? I suppose so. And I retract my statement on the image/tiff-fx precedent above. The rationalization in the appendix for RFC3023 (https://tools.ietf.org/html/rfc3023#page-32) makes it seem like they would have ultimately been better off with image/fx+tiff (and, thus, image/cog+tiff would be better). Whether or not the guidelines for registering tiff as a structured syntax name can be easily met (I would guess so, but it doesn't appear to be used that manner yet and that registration process seems more onerous than the media type registration itself) someone will have to figure out.

EmDevys commented 5 years ago

Thanks to all for contributions and material. Trying to summarize here, in order to facilitate conclusion and decision on this potential issue. Normative References / Context 1- IANA: https://tools.ietf.org/html/rfc3302 Tag Image File Format (TIFF) - MIME Sub-type Registration => MIME type / subtype: image/tiff + application parameter (optional) MIME type identifies Media content, subtype identifies encoding. Example: image/tiff; application=foo 2- https://tools.ietf.org/html/rfc6838 (Media Type Specifications and Registration Procedures – see 4.2. Naming Requirements and use of a final "+" in a subtype name) 3- OGC registered Media Type and OGC practice. Based on IANA registry, the pattern is {schema}+{encoding} (ex. GML is gml+xml). 4- OGC WCS GeoTIFF extension: image/tiff cf. OGC GMLCOV GeoTIFF extension (OGC 12-100r1) specifies image/tiff as MIME identifier (cf. Requirement #5). Cf. issue and discussions on https://github.com/opengeospatial/geotiff/issues/34

Some other common usages

Options for GeoTIFF file MIME type 1- Recommend image/geo+tiff as recommended by Mathias Mohr and OGC NA (requires submission to IANA + adjustment of OGC GMLCOV GeoTIFF extension) 2- Keep image/tiff, use optional application parameter: image/tiff; application=geotiff (this one presumably does not requires any IANA submission) 3- Use of application/x-geo+tiff or application/geotiff or application/x-geotiff, as well as vnd tree (software vendors). (This option does not use the image content type) Note: for backward compatibility, this 1.1 minor revision should presumably recommend one of the 2 first options, though allowing other options.

Recommendation any of option 1 or 2 seems acceptable (to me) - TBD The GeoTIFF.SWG, WCS and WPS SWGs and OGC should analyze the most adequate option (and having minimum impact of existing specification).

EmDevys commented 5 years ago

Even Rouault email (13/06/2019) results of my Tweeter polls after a 2-day vote period are at https://twitter.com/EvenRouault/status/1138476398954319873

Inline 65 participants:

Sean Gillies, one of the author of the GeoJSON spec, pointed that IANA would have the final word on this, and would likely pick application/geo+tiff, pointing to https://tools.ietf.org/html/rfc6838#section-4.2.5, for consistency with the application/geo+json precedent. Another participant also mentionned that image/tiff didn't make sense to him, as in a number of cases GeoTIFF is used to convey other thinks than (visual) images: DEMs, etc... Another one said "whatever you decide is fine, but decide for one", and I tend to agree that a dice roll is probably not to be worse than any rational considerations in such a fuzzy field as MIME naming :-)

EmDevys commented 5 years ago

SWG + OpenOAB decision (26 June) Per OAB andGeoTIFF.SWG: Media type = Image/tiff; application=GeoTIFF, develop an RFC in accordance with RFC 3302 and contact IANA. Cloud optimized GeoTiffs are out of scope of this minor revision 1.1

m-mohr commented 5 years ago

Thanks for the information @EmDevys .

I'm aware that COGs are out of scope, but did you generally spoke or thought about how to handle subtypes?

For example, COGs could be image/tiff; application=CloudOptimizedGeoTiff (so not a subtype of GeoTiff) or image/tiff; application=geotiff; cloud-optimized=true.

Not sure whether there are other GeoTiff derived formats out there?

EmDevys commented 5 years ago

No we only discussed whether we could identify GeoTIFF with the MIME type, without breaking existing rules / RFC. Image/tiff is already a subtype.

Probably (IMHO) Cloud optimized resources (not only GeoTIFF) should have a way to be identified as such (on basis of MIME type) but I’m not aware of this (My apologize). To my knowledge, the RFC 3302 presently only allows the application parameter. Whether a second parameter (such as cloud-optimized=true) is allowable by IANA, or another value such as CloudOptimizedGeoTiff for the parameter, or any other mechanism (such as geotiff+cog) could be discussed, assessed and if considered of interest submitted to the OGC, then the IANA. As Gobe Hobona and Scott Simmons are in charge of the relation with IANA, I copy them to this email.

De : Matthias Mohr [mailto:notifications@github.com] Envoyé : mardi 23 juillet 2019 10:50 À : opengeospatial/geotiff Cc : Emmanuel Devys; Mention Objet : Re: [opengeospatial/geotiff] Media (MIME) type for GeoTIFF (#34)

Thanks for the information @EmDevyshttps://github.com/EmDevys .

I'm aware that COGs are out of scope, but did you generally spoke or thought about how to handle subtypes?

For example, COGs could be image/tiff; application=CloudOptimizedGeoTiff (so not a subtype of GeoTiff) or image/tiff; application=geotiff, cloud-optimized=true (not sure whether multiple parameters are even allowed, but in this case it's hard to define sub types?!).

Not sure whether there are other GeoTiff derived formats out there?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/geotiff/issues/34?email_source=notifications&email_token=ACDHG2XVXDAPRIUH62ACPBDQA3A4PA5CNFSM4FUUMMX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2SMZLA#issuecomment-514116780, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACDHG2RY6FB2JJAFTTTRLE3QA3A4PANCNFSM4FUUMMXQ.

m-mohr commented 5 years ago

According to RFC 2045, sec. 5.1, multiple parameters are allowed in Content-Type headers. See the ABNF of content.

EmDevys commented 5 years ago

Thanks for information. As parameter may be multiple, may be in this case should be parameter=geotiff ; parameter=cog ? Does this make sense?

I considered this issue closed for GeoTIFF 1.1, but may be it should be kept open for evolutions such as GeoTIFF 1.2 or later…

De : Matthias Mohr [mailto:notifications@github.com] Envoyé : mardi 23 juillet 2019 11:33 À : opengeospatial/geotiff Cc : Emmanuel Devys; Mention Objet : Re: [opengeospatial/geotiff] Media (MIME) type for GeoTIFF (#34)

According to RFC 2045, sec. 5.1https://tools.ietf.org/html/rfc2045#section-5.1, multiple parameters are allowed in Content-Type headers. See the ABNF of content.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/geotiff/issues/34?email_source=notifications&email_token=ACDHG2T5K3YP6HDV6VGOJULQA3F6HA5CNFSM4FUUMMX2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2SQU5Y#issuecomment-514132599, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACDHG2QETGQ7FWCWI5JPZPDQA3F6HANCNFSM4FUUMMXQ.

m-mohr commented 5 years ago

Something like image/tiff; application=geotiff; cloud-optimized=true would make sense. But I guess "sub types" of GeoTiff as COG can just define what they want as long as they just add another parameter to image/tiff; application=geotiff.

bradh commented 5 years ago

If we're going to add parameters to support COG, I'd prefer to see identification of properties: does it have tiles (boolean or maybe what size), and does it have overviews (boolean or maybe what powers).

m-mohr commented 5 years ago

@bradh I don't think the GeoTiff spec needs to add anything regarding COG here. But the COG spec can specify its own media type and base it on the GeoTiff media type by adding a parameter. So I don't think there will be parameters in the GeoTiff spec?!

bradh commented 5 years ago

If there is a need to be descriptive about certain characteristics of GeoTIFF, then the GeoTIFF MIME type could include that - COG is still meant to be valid GeoTIFF, and if you don't care about tiling and/or overviews, you can treat what you have as GeoTIFF. So a (moderate) preference for not treating that variation as a different media type.

philvarner commented 5 years ago

So the COG media type variant would be like

image/tiff; application=geotiff; tiled=true; tile-size=256; overviews=true; compress=DEFLATE;

and then the determination of "COGness" would be up to the user, e.g., compression in optional but highly recommended, tile-size should be <= 512 but isn't required to be. The client can then determine from all those properties what actions (like range reads) they want to do.

adoyle commented 5 years ago

I agree with @m-mohr

I think it's up to the COG developers to determine this and decide how to extend the media type for their purposes. There's a parallel discussion on the COG list about this right now at https://lists.osgeo.org/pipermail/cog/2019-July/000067.html

The most the GeoTIFF SWG should do would be to indicate that specializations of the GeoTIFF format might also extend the media type and that GeoTIFF parsers should not reject media types that contain unknown keys.

bradh commented 5 years ago

Whether it makes more sense to do it as a "COG thing" or a "SWG thing" depends on whether there is ever likely to be another profile that makes use of this information. If its broader than COG, then describe it here. If it is just COG, describe it in COG, and just facilitate it here.

I could well see additional profiles (e.g. NGA likes them, DGIWG seems to do it a lot), so I think having common parameters in the GeoTIFF spec (and MIME registration - IANA isn't going to let everyone go crazy on the OGC's submission) is probably better.

p3dr0 commented 4 years ago

FYI I sent this suggestion on the cog@lists.osgeo.org back in July

I would suggest the usage of the profile link relation image/tiff; profile= < URI-reference >

the value to be defined (for example it could be https://www.cogeo.org/ )

Further reading at https://tools.ietf.org/html/rfc6906#section-3.1 and check also https://ruben.verborgh.org/articles/fine-grained-content-negotiation/

FYI this is already being used by GML https://www.iana.org/assignments/media-types/application/gml+xml

cholmes commented 3 years ago

SWG + OpenOAB decision (26 June) Per OAB andGeoTIFF.SWG: Media type = Image/tiff; application=GeoTIFF, develop an RFC in accordance with RFC 3302 and contact IANA.

Did this actually get submitted to IANA? It'd be useful for us in STAC to refer officially somewhere to this.

EmDevys commented 3 years ago

Scott You were supposed to handle the relation with IANA, could you please indicate the progress of this action?

Thanks in advance Emmanuel

De : Chris Holmes [mailto:notifications@github.com] Envoyé : jeudi 28 janvier 2021 06:04 À : opengeospatial/geotiff Cc : Emmanuel Devys; State change Objet : Re: [opengeospatial/geotiff] Media (MIME) type for GeoTIFF (#34)

SWG + OpenOAB decision (26 June) Per OAB andGeoTIFF.SWG: Media type = Image/tiff; application=GeoTIFF, develop an RFC in accordance with RFC 3302 and contact IANA.

Did this actually get submitted to IANA? It'd be useful for us in STAC to refer officially somewhere to this.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/geotiff/issues/34#issuecomment-768801583, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACDHG2TZRTSIMBNI5PJLCJTS4DV3XANCNFSM4FUUMMXQ.

ogcscotts commented 3 years ago

In short, such a registration with IANA is not possible. Read the IANA response below and consider if we want to apply for a completely new media type.

It seems that the process continued in email threads and was not updated on this Issue. We applied to IANA for registration and after significant discussion between us and IANA, we were informed that parameters could not be registered. The IANA response is as follows.

"The short answer is no, there is no such thing as a separate media type parameter registry.

The long answer is that parameters have to be defined when the media type is defined; adding additional parameters can only be done by updating the registration, and in the case of standards tree types, the associated specification. Alternately, you could define a new media type that's the same as the original but adds one or more parameters. I believe we've done this in the past.

As for the so-called sub-parameter registry - a very poor choice of names IMO - these are registries for additional parameter values, not additional parameters. And such registries have to be defined as part of the original media type specification.

In the specific case of image/tiff, modifying the original media type specification isn't really an option. So OGC's remaining option is to define their own media type with the additional parameter they need."

joanma747 commented 2 years ago

The conclusion of this issue that affects GeoTIFF is that image/tiff; application=geotiff is correct with IANA. We can close this issue here.

An issue in COG repo was open to discuss about this: https://github.com/opengeospatial/CloudOptimizedGeoTIFF/issues/1

m-mohr commented 2 years ago

I don't understand the conclusion as the message from @joanma747 seems to be in conflict with what @ogcscotts posted:

@joanma747 says image/tiff; application=geotiff is fine with IANA @ogcscotts says image/tiff; application=geotiff can't be registered with IANA

Can you clarify? Do we just use image/tiff; application=geotiff without registration?

joanma747 commented 2 years ago

https://www.iana.org/assignments/media-types/image/tiff already defines "application" as the ONLY parameter you can use. No other parameter can be added the Media Type without IANA "blessing". This creates a problem for COG where more parameters are needed. My understanding is that @ogcscotts is talking about other than application.

m-mohr commented 2 years ago

That makes sense, thanks.

EmDevys commented 2 years ago

Yes, and for plain GeoTIFF (not COG), this is what was specified, after some investigation at IANA. See section 8 I n OGC GeoTIFF 1.1, http://docs.opengeospatial.org/is/19-008r4/19-008r4.html#_media_types_for_geotiff_data_encoding

De : Matthias Mohr @.*** Envoyé : mardi 26 octobre 2021 17:09 À : opengeospatial/geotiff Cc : Emmanuel Devys; State change Objet : Re: [opengeospatial/geotiff] Media (MIME) type for GeoTIFF (#34)

That makes sense, thanks.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/geotiff/issues/34#issuecomment-952036603, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACDHG2VG7CC6G3SRRZDWFNDUI3HA3ANCNFSM4FUUMMXQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.