Opened 8 years ago

Last modified 7 years ago

#1796 new task

remotesensing.org control being lost and geotiff pages

Reported by: rouault Owned by: sac@…
Priority: normal Milestone:
Component: SysAdmin Keywords:
Cc:

Description

http://remotesensing.org/geotiff used to host the HTML pages of the libgeotiff project (and more generally the GeoTIFF specification), but Marc Lucas recently took control back to remotesensing.org, so the domain is lost for our own use.

http://remotesensing.org/geotiff used to redirect to http://geotiff.osgeo.org, which redirects to http://trac.osgeo.org/geotiff

I would suggest that if possible http://geotiff.osgeo.org to know serve the content of https://svn.osgeo.org/metacrs/geotiff/trunk/geotiff/html/ ,which was the likely source for the content previously expose. I guess this could be done by a cron job doing a svn update on a daily basis for example. Is that possible ?

Change History (9)

comment:1 by Jeff McKenna, 8 years ago

Note that I was strongly suggesting to the libgeotiff community that OSGeo can handling this hosting, but no consensus was made on the mailing list.

I am +1 to move ahead anyway, as suggested by Even.

comment:2 by rouault, 8 years ago

Jeff, I guess you must confuse with the libtiff community, since both libtiff and libgeotiff were hosted by remotesensing.org.

Regarding libtiff, its hosting by osgeo.org can be discussed since it is not a OSGeo project or community project (although being a critical dependency!), and as you said no clear concensus emerged about what to do with libtiff.

But libgeotiff is clearly a OSGeo community project (associated with MetaCRS), so we should do something to fix the current situation.

comment:3 by Jeff McKenna, 8 years ago

sorry yes you are right of course.

comment:4 by Jeff McKenna, 8 years ago

Oddly I didn't see any of this discussed on the libgeotiff mailing list (only on the libtiff mailing list), I guess that is why I was confused.

comment:5 by martin, 8 years ago

So, Even, you simply want http://geotiff.osgeo.org/ to serve the content of the SVN repo subdir *instead* of redirecting to Trac ? This can probably be done by tweaking the WebDAV interface which already serves the SVN repo to HTTP, without the need of regular checkouts ....

in reply to:  5 comment:6 by rouault, 8 years ago

Replying to martin:

So, Even, you simply want http://geotiff.osgeo.org/ to serve the content of the SVN repo subdir *instead* of redirecting to Trac ? This can probably be done by tweaking the WebDAV interface which already serves the SVN repo to HTTP, without the need of regular checkouts ....

Given the possibility you mention, perhaps we could let http://geotiff.osgeo.org/ redirect to https://trac.osgeo.org/geotiff/ , if I could make the links there to point to HTML pages of SVN and display them as HTML (e.g. "GeoTIFF Revision 1.0 Specification" pointing to https://svn.osgeo.org/metacrs/geotiff/trunk/geotiff/html/spec/contents.html . Currently somebody has corrected it to point to a wayback machine URL )

comment:7 by rouault, 7 years ago

Just a friendly ping if anything can be done for those geotiff html pages ?

comment:8 by Jeff McKenna, 7 years ago

I offered this to the libgeotiff community but they were unwilling to accept. Can you also try asking them?

comment:9 by Jeff McKenna, 7 years ago

ah I guess I am again confused with libtiff! :)

Note: See TracTickets for help on using tickets.