#1335: g.region compilation fails with recent proj
+---
Reporter: martinl | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker |
Glynn Clements wrote:
>
> Markus Metz wrote:
>
>> The segment lib implementation in trunk is considerably faster than in
>> 6.x, but not as efficient as the caching method of r.proj. Some
>> reasons why the segment library is slower than the caching code in
>> r.proj are 1) write support in the seg
Hi,
2011/4/8 Sudeep Singh :
> I am applying for GSOC's WXGUI project. I have few queries and want to
> discuss them. I have done work in GIS development in an 1 year project.
are you interested at some topic mentioned on the wiki [1], or you
have your own idea?
Regards, Martin
[1] http://grass.
2011/4/8 Sudeep Singh :
> yes, I am interested in the topic mentioned at wiki.
>
> GRASS wxGUI
OK, but which one...? There are plenty topics mentioned on this page.
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
gra
2011/4/8 Sudeep Singh :
> I thought that all ideas under WXGUI are a single project.
not at all :-)
> I am more keen on
> "Add WMS and/or TiledMapService and/or WMS-T layer support for wxGUI.
> Tiles/WMS images should not be stored as GRASS rasters but only used for
> displaying purposes (i.e. st
Hi all,
Could anyone here please suggest if I understand the problem statement well
or am i missing something, If i am missing then please let me know of the
basic requirement I am missing.
"Add *WMS and/or TiledMapService and/or WMS-T layer support* for wxGUI.
Tiles/WMS images should not be sto
#1344: Ibiblio mirror: 403 Forbidden
--+-
Reporter: hamish| Owner: grass-dev@…
Type: defect| Status: new
Priority: critical | Milestone: Website
Hello,
anyone have esperience of how running r.what or d.what rast on the *Map
Display* from the shell?
I am developing an user friendly interface for a GRASS script and I want
digitalize two points without using v.digit, but in a more user-friendly
(perhaps...) procedure.
Anyone have any ideas?
Markus Metz wrote:
> > It wouldn't be particularly hard to structure the r.proj tile cache
> > code such that the tile size can be set by the module, so long as it's
> > set at compile time. Allowing the tile size to be set at run time
> > incurs an inevitable performance penalty.
>
> That means
#1335: g.region compilation fails with recent proj
+---
Reporter: martinl| Owner: grass-dev@…
Type: defect | Status: closed
Priority: blocker| Milestone:
#1300: WxGUI measure tool gives wrong results
--+-
Reporter: marisn| Owner: grass-dev@…
Type: defect| Status: new
Priority: blocker | Milestone:
#1262: r.proj broken in all dev versions
--+-
Reporter: cmbarton | Owner: grass-dev@…
Type: defect| Status: new
Priority: critical
#1262: r.proj broken in all dev versions
--+-
Reporter: cmbarton | Owner: grass-dev@…
Type: defect| Status: new
Priority: critical
13 matches
Mail list logo