Re: Packages maintained by Debian GIS but not mentioned in metapackages
Hi Andreas,
Il 14/03/2013 14:43, Andreas Tille ha scritto:
Hi,
[CUT]
So I was running some Blends tool to check whether all packages
maintained by
Debian GIS Project <pkg-grass-devel@lists.alioth.debian.org>
are properly mentioned in the Debian GIS tasks files and detected
several missings. I admit that I'm no GIS expert at all and have real
problems to categorise these packages into the proper tasks (either
existing ones or to be created tasks). I would like to ask for help
where to check the following list. I listed binary package - short
description and if I somehow feelt that it makes some sense I added
the package to a task marked by "--> <taskname>". Please check
whether you confirm with this. Those I were totally unsure about
are marked by ??? with suggestions in ():
dans-gdal-scripts - GDAL contributed tools by Geographic Information Network of Alaska
--> sar
+1
gmt-coast-low - Low resolution coastlines for the Generic Mapping Tools
gmt-gshhs-full - Full resolution coastlines for the Generic Mapping Tools
gmt-gshhs-high - High resolution coastlines for the Generic Mapping Tools
gmt-gshhs-low - Low resolution coastlines for the Generic Mapping Tools
--> ??? ('sar', or even to be created 'data'?)
there is some package in the remote sensing task that depends on GMT but
IMO the coastline data can't be considered specific of that task.
+1 doe data
h5utils - HDF5 files visualization tools
--> workstation
libjts-java - JTS Topology Suite
--> workstation
libgdal1-1.9.0-grass - GRASS extension for the GDAL library
--> sar
workstation IMO
libgeo-proj4-perl - PROJ.4 library for cartographic projections
--> workstation (only Suggests, because seems to be rather a dependency
of other packages - probably fits good into devel (see
below))
libgeo-point-perl - module to simplify handling geographic points
--> workstation
libosm-gary68-perl - OpenStreetMap perl module
--> osm
geotiff-bin - the GeoTIFF library -- tools
--> workstation
libkml-java - A library to manipulate KML 2.2 OGC standard files - Java package
python-kml - A library to manipulate KML 2.2 OGC standard files - Python extension
--> workstation (only suggested, because quite development oriented - see below)
liblas-bin - ASPRS LiDAR data translation toolset
--> workstation (should it rather be sar??)
rasterlite-bin - command line tools for librasterlite
--> workstation
BTW, the dscription is pretty useless and should not be only
understandable by insiders
nco - command-line operators to analyze netCDF files
ncview - A X11 visual browser for NetCDF format files
netcdf-bin - Programs for reading and writing NetCDF files
--> workstation + sar (only suggested for the moment because it seems not
specifically GIS oriented even if useful for GIS tasks ... at least to
my poor understanding)
osgearth - Dynamic 3D terrain rendering toolkit for OpenSceneGraph (binaries)
--> workstation
python-epr - Python ENVISAT Product Reader API (Python 2)
python-pyshp - read/write support for ESRI Shapefile format
--> workstattion (only suggested because API and no application -
see below)
python-epr is already in the remote sensing task but IMO workstation
and/or dev is also OK
python-pyproj - Python interface to PROJ.4 library
--> workstation
spatialite-bin - Geospatial extension for SQLite - tools
spatialite-gui - user-friendly graphical user interface for SpatiaLite
--> workstation
libreadosm-dev - simple library to parse OpenStreetMap files - headers
--> osm (only suggests, see below)
tilecache - a web map tile caching system
tilelite - lightweight Mapnik tile-server
tilestache - map tiles caching system
--> osm (but with a very bad feeling here - it rather belongs to some
not yet existing task osm-server IMHO)
totalopenstation - download and process data from total station devices
(currently only in NEW but Blends web sentinel is aware about packages
in NEW)
--> tools (just invented this task - could profit from your input
what could fit here as well)
I also wonder what you might think about developer oriented tasks which
are used in Debian Med and Debian Science. We could either split these
into different topics like
gis-gps-dev, gis-osm-dev, etc. or simply
gis-dev
featuring development library packages like for instance
libepr-api2-dev, libgeo-proj4-perl, libgeotiff-dev,
libgrits-dev, libkml-java, python-kml, libkml-dev,
libterralib-dev, python-epr, python-pyshp, libreadosm-dev,
libspatialindex-dev
python-gdal IMO belongs to the same category
It would be great if you GIS experts could have a thorough look at the
resulting tasks page of the web sentinel[4] to see whether all my
changes would make sense or not.
I would consider uploading a new set of debian-gis metapackages
targeting at Wheezy where we will probably get permission for
considering my request to Debian Release team[5] (even if I forgot
to mention debian-gis in this very mail.) The rationale is to
advertise Debian GIS amongst Wheezy users as best as possible and
thus making people aware that there is a team that cares for GIS
applications and might be interested in fresh blood.
Kind regards
Andreas.
[1] http://chemnitzer.linux-tage.de/2013/vortraege/164
[2] https://wiki.debian.org/DebianMed/Developers
[3] http://people.debian.org/~tille/talks/201302_fosdem_distro/
[4] http://blends.alioth.debian.org/gis/tasks/
[5] https://lists.debian.org/debian-release/2012/06/msg00323.html
the task file for the remote sensing task is currently sar.
I don't know if the task file name has any relevance in the process of
metapackages generation.
If it does you should consider to rename the task file: remote sensing
is a wider scope with respect to SAR (Synthetic Aperture Radar)
cheers
--
Antonio Valentino
Reply to: