Hi,
submission rules shouldn't change too often and thus maintaining two
versions (GRASS 6 vs 7) shouldn't be a huge issue. Keeping them with
source has a benefit of being able to distribute them with source :)
Are there any other benefits besides "updating two versions"?
Just my 0.002 Verizon ce
This is really odd.
I've been using GRASS 7 (compiled yesterday) trying to patch together a 90m DEM
with ocean data downscaled from an ETOP2 DEM.
I repeatedly was getting files with a resulting resolution of NS Res:
0:00:50.139276 and EW Res: 0:00:53.20197 even though I repeatedly set the
res
Hi,
currently we need to maintain submission rule files in three different
branches (trunk, devbr6, relbr64). I would suggest to move these
documents from SVN to trac, similarly to GDAL [1]. In our case
something like
http://trac.osgeo.org/grass/submittingC
http://trac.osgeo.org/grass/submittingP
#1217: d.vect -a flag locks up the wxGUI on windows
--+-
Reporter: RenatoMacciotta | Owner: martinl
Type: defect| Status: assigned
Priority: blocker | Milestone:
2012/4/12 Markus Metz :
>>> mapset Name(s) of existing mapset(s)
>>> addmapset Name(s) of existing mapset(s) to add to search path
>>> removemapset Name(s) of existing mapset(s) to remove from search path
>
> BTW, these options exist for g.mapsets, not for g.mapset.
sure, sorry fo
On Thu, Apr 12, 2012 at 7:14 PM, Luca Delucchi wrote:
> 2012/4/12 Martin Landa :
>> Hi,
>>
>> `g.mapset` has currently several options to set/add/remove mapsets
>> from the search path
>>
>> mapset Name(s) of existing mapset(s)
>> addmapset Name(s) of existing mapset(s) to add to sea
2012/4/12 Martin Landa :
> Hi,
>
> `g.mapset` has currently several options to set/add/remove mapsets
> from the search path
>
> mapset Name(s) of existing mapset(s)
> addmapset Name(s) of existing mapset(s) to add to search path
> removemapset Name(s) of existing mapset(s) to remo
Hi,
`g.mapset` has currently several options to set/add/remove mapsets
from the search path
mapset Name(s) of existing mapset(s)
addmapset Name(s) of existing mapset(s) to add to search path
removemapset Name(s) of existing mapset(s) to remove from search path
I would suggest
2012/4/12 Martin Landa :
> 2012/4/12 Markus Neteler :
>> I see some troubles in the logs:
>> http://wingrass.fsv.cvut.cz/grass64/logs/
>>
>> "cp: cannot stat `/c/OSGeo4W/lib/proj.lib': No such file or directory"
>
> it's due recent update of proj (4.8.0)
>
> \in_progress re-building all branches...
On 12/04/12 12:29, Andres Kuusk wrote:
In the manual I read: It is possible to link the geographic objects in a
vector map to one or more tables.
All vector objects are kept in one geometry file, and topology is
maintained for all vector objects together. GRASS layers only consist of
links to dif
Yes, user have to insert EPSG number.
So far, It is implemented only getMap request, which is in responsibility of
the module r.in.wms2. In r.in.wms2 GetCap response is only printed in output
btw. there was bug in r.in.wms2 getCapabilities, i have just fixed it.
I want to implement parsing of
Stepan,
by lack of time I didn't yet test your new module, but I see the user is
asked to fill in the projection system of layers he requests. Am I
right ? I just wonders if you had tried to implement the ability to
self-evaluate this parameter: getting that information is possible via a
GetCapabil
All removed examples used service[1], which no longer provides standard WMS
access.
I will try to add more examples.
Stepan
[1] http://onearth.jpl.nasa.gov/(http://onearth.jpl.nasa.gov/)
-- Původní zpráva --
Od: Martin Landa
Datum: 12. 4. 2012
Předmět: [GRASS-dev] Re: [GRAS
Hello,
WMS-c or WMTS would be possible to implement into r.in.wms2.
After finishing standard wms support implementation for GRASS and SAGA I
will take a deeper look at it.
Stepan
-- Původní zpráva --
Od: Vincent Bain
Datum: 7. 4. 2012
Předmět: Re: [GRASS-dev] Applyin
2012/4/12 Markus Neteler :
> I see some troubles in the logs:
> http://wingrass.fsv.cvut.cz/grass64/logs/
>
> "cp: cannot stat `/c/OSGeo4W/lib/proj.lib': No such file or directory"
it's due recent update of proj (4.8.0)
\in_progress re-building all branches...
Martin
--
Martin Landa * http://
On Thu, Apr 12, 2012 at 8:37 AM, Maris Nartiss wrote:
> Hi,
> seems that there are no more WinGRASS nightly builds provided for 6.4.
>
> I wanted to test out fixes in WXGUI on Windows platform, but could not
> find the installer :(
I see some troubles in the logs:
http://wingrass.fsv.cvut.cz/gras
16 matches
Mail list logo