Re: [GRASS-dev] Size of the volume_layout image
Vaclav:
> After consultation with Sören, I changed the image size (old size
> file preserved). I also added simple README and renamed the images to
> one unified name.
Hi,
anyone have hints if width="x" or width="x%" in the is enough
to take care of the scaling? (some browsers rescale ugly, others blend)
e.g. I put a fairly large dimension screenshot into the G6 d.correlate.sh
help page yesterday:
https://trac.osgeo.org/grass/changeset/57779
good/no good?
> Changeset:
> https://trac.osgeo.org/grass/changeset/57780
How about using svn symlinks? Then there is only wasted space on Windows and
the g_module_imgname.{png,jpg} naming convention for help page images could be
preserved.
(Subversion takes care of all the platform details)
or probably better just have the main r3 intro doc supply the image, then just
have the other help pages to it assuming that it will be there in
$GISBASE/docs/. I don't think it even needs "../" since they all live in the
same install dir.
gimp can read+write compressed files directly, so suggest to keep any .xcf
files in svn as .xcf.bz2. (note mime-types remain on the internal content type,
not the compression type used.)
perhaps the README should mention that r3.out.vtk + Paraview was used to make
the screenshot? (it looks like it anyway) Also, I'd also suggest to rename the
README to something more specific as it sits in a top-level dir and one might
assume it contains high-level instructions.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Size of the volume_layout image
After consultation with Sören, I changed the image size (old size file preserved). I also added simple README and renamed the images to one unified name. Changeset: https://trac.osgeo.org/grass/changeset/57780 Result will be visible here: http://grass.osgeo.org/programming7/raster3dlib.html http://grass.osgeo.org/grass70/manuals/raster3dintro.html http://grass.osgeo.org/grass70/manuals/r3.out.ascii.html http://grass.osgeo.org/grass70/manuals/r3.in.ascii.html On Fri, Sep 20, 2013 at 12:25 AM, Vaclav Petras wrote: > Hi, > > the image `volume_layout` is just too big. It is included in both user and > programming manual. The problem is not the size in MB but just the fact > that it is too large to show on the screen when it is part of the web page. > > I think that width 500 is sufficient to see all details. > > I would just change the size but I don't know how the image was generated > or if we want to have the full size image somewhere. > > Vaclav > > > In src: > ./lib/raster3d/volume_layout.png > ./html/volume_layout.png > ./raster3d/r3.out.ascii/g3d_volume_layout.png > ./raster3d/r3.in.ascii/g3d_volume_layout.png > > In dist: > ./docs/html/g3d_volume_layout.png > > Online: > http://grass.osgeo.org/programming7/raster3dlib.html > http://grass.osgeo.org/grass70/manuals/raster3dintro.html > http://grass.osgeo.org/grass70/manuals/r3.out.ascii.html > http://grass.osgeo.org/grass70/manuals/r3.in.ascii.html > ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.mapcalc
Vaclav wrote: > when I saw recent changes [1] in > grass/trunk/vector/v.mapcalc/ > I realized that there is a v.mapcalc in trunk (compilation is disabled). > However, here is also a v.mapcalc in GSoC project for temporal algebra [2]. > > I'm wondering how they compare with each other for the old GRASS 5 v.mapcalc which is the subject of the trac ticket, you can read about it here: https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.mapcalc/README and for the temporal GIS v.mapcalc Thomas's wiki page that you linked to does a nice job. AFAICT the old one is looking at math more than spatial, so perhaps a bit more like v.transform might be, than e.g. the functionality of v.overlay or v.select's GEOS tools as the temporal version might be more focused on? (I'm not really sure though, I'm just going from what I see in the README) How the eventual-goals of both of these modules compare with what general-purpose vector ops can be done using PostGIS would be interesting to know too. > and what is the plan? I would suggest step 1 to be your question- understand and take an inventory of what we tools we already have, and what state they are in. Choosing the best names for things can come after that. Of course for the long run we should avoid name-space collisions if we can. regards, Hamish >[1] https://trac.osgeo.org/grass/ticket/1321 >[2] >http://grasswiki.osgeo.org/wiki/GRASS_GSoC_2013_Temporal_GIS_Algebra_for_raster_and_vector_data_in_GRASS#v.mapcalc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] v.mapcalc
Hi, when I saw recent changes [1] in grass/trunk/vector/v.mapcalc/ I realized that there is a v.mapcalc in trunk (compilation is disabled). However, here is also a v.mapcalc in GSoC project for temporal algebra [2]. I'm wondering how they compare with each other and what is the plan? Best, Vaclav [1] https://trac.osgeo.org/grass/ticket/1321 [2] http://grasswiki.osgeo.org/wiki/GRASS_GSoC_2013_Temporal_GIS_Algebra_for_raster_and_vector_data_in_GRASS#v.mapcalc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
