[GRASS-dev] Location EPSG code storage
Hello all, as EPSG codes have become de-facto standard way of identifying various SRS'es in various services and other places, we need a way how to sore locations EPSG code, if it's known. Currently when creating a new location by EPSG code, this information gets lost. There is no easy way how to determine current location EPSG code required to connect any OGC WxS service. Comparing proj parameters from epsg file is not failproof. Options: a) add a new key-value pair to PROJ_INFO + all information is stored in single place + projection information reading/writing code is already inplace - it needs to be changed to deal with a new key-value pair - breaks backwards compatibility - EPSG code might not be known for most of (existing) locations b) create a new file (epsg) in PERMANENT + doesn't affect current projection information management - information lives separate from rest of projection information - requires new functions to read/write this info I would like to hear other developer opinion before any changes to core parts are implemented. Maris. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1158: Removing vector map in Windows fails with Unable to delete vector map
#1158: Removing vector map in Windows fails with Unable to delete vector map --+- Reporter: lponti| Owner: grass-dev@… Type: defect| Status: new Priority: blocker | Milestone: 6.4.2 Component: Vector| Version: 6.4.0 Keywords: wingrass, g.mremove, wildcards, v.in.ogr, v.select, g.remove | Platform: MSWindows 7 Cpu: Unspecified | --+- Comment(by mmetz): Replying to [comment:44 glynn]: Replying to [comment:42 mmetz]: Do the small differences in lib/gis/spawn.c between trunk and 6.4 really make sense? No; that file should be sync'd from trunk to 6.x. Done in r47965 and r47968 for 6.5 and 6.4, respectively. db_shutdown_driver() fixed in r47966 and r47969 for 6.5 and 6.4, respectively. The call to Vect_delete() by g.remove, g.mremove, v.in.ogr or any other module allowed to overwrite an existing vector map works for me now in Windows. Please confirm. Markus M -- Ticket URL: https://trac.osgeo.org/grass/ticket/1158#comment:45 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Location EPSG code storage
- Maris Nartiss maris@gmail.com napisał: Options: a) add a new key-value pair to PROJ_INFO + all information is stored in single place + projection information reading/writing code is already inplace - it needs to be changed to deal with a new key-value pair - breaks backwards compatibility - EPSG code might not be known for most of (existing) locations Yes (with code epsg not known for locations without epsg) This solution does not create a new file. All projection parameters are in one file. Regards Pawel ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] where to store GRASS settings: GISRC and wx settings
On Mon, Aug 29, 2011 at 11:11 PM, Hamish hamis...@yahoo.com wrote: Hamish: please revert unix ~/.grassrc6 bits of r47956 for 6.5 immediately. Martin: disagreed. Martin if our opinions cancel each other out, the matter is up to the consensus of the rest of the group then. If the discussion is going on like this, the heat death of the universe is coming faster than we think... In general I think it is a good idea to have all the settings and other stuff, e.g. grass-addons, in one single folder, and not scattered around. But that is a design change already implemented in grass7. Since there seems to be a majority to not introduce these changes to 6.x, I will revert the changes I did to 6.5 and also change some backports from trunk to 6.x regarding the file where wxGUI settings are stored, i.e. 6.x shall use .grasswx6 as in pre-6.4.2. The status quo is thus for 6.x use .grassrc6 and .grasswx6, located in $HOME (%USERPROFILE% for Windows) and for 7 use .grass7/rc and .grass7/wx, located in $HOME (grass7\rc and grass7\wx, located in %APPDATA% for Windows) BTW, the NSIS script for the Windows installer should IMHO not change the location and file name of GISRCRC, this should be defined at as few places as possible for easier maintenance (grass.py for trunk). Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] where to store GRASS settings: GISRC and wx settings
2011/8/30 Markus Metz markus.metz.gisw...@googlemail.com: if our opinions cancel each other out, the matter is up to the consensus of the rest of the group then. If the discussion is going on like this, the heat death of the universe is coming faster than we think... unfortunately the discussion is going like this everytime you touch holy cow - GRASS 6.4 ;-) That's frustrating, on the other hand it forces you to develop GRASS 7;-) Nothing to say more. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Create new branch from trunk for temporal GIS integration
Hi, [snip] I had a private branch of trunk for more than a year when developing and testing new vector topology. It was not always easy to keep it working, although I only had to svn up to get in sync with the official trunk. This is not so easy when creating a real branch of trunk in svn. But if you feel more comfortable with a separate branch for experimenting then do it. I wanted to warn, but of course will assist you whatever your decision. After some experimenting and the development of simple prototypes (getting very frustrated with the db library ... ) i decided to use python for all the temporal logic, library and modules. The modification in GRASS core libraries will be minimized. Only a few C library functions are planed in the future, implementing the INSERT/UPDATE/DELETE SQL queries for raster, vector and raster3d maps in the location specific time and metadata database. The consequence is: * Using sqlite3 exclusively, no support for other databases as backend (Unfortunately the implementation of trigger and temporal logic is database specific ...) * Implementation of all the temporal logic in python * Using an OO approach to reflect the theory of generalized fields [Liu and Goodchild 2008] * Using sqlite3 python library directly to have full datatype support and python based sqlite3 user functions * Using a location wide database rather than a mapset specific one, to store the temporal and metadata information for all mapsets, primary key will be name@mapset Because of the minimized footprint of this approach in the GRASS core libraries, i decided to implement the temporal GIS extension in trunk. So no new branch is needed. Thanks for all your suggestions and comments. Cheers Soeren Markus M The branch should only exist for experimenting and rapid development and merged ASAP. Best regards Soeren ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #948: wxGUI vector layer field broken
#948: wxGUI vector layer field broken --+- Reporter: mmetz| Owner: grass-dev@… Type: defect | Status: closed Priority: blocker | Milestone: 7.0.0 Component: wxGUI| Version: svn-releasebranch64 Resolution: fixed|Keywords: wxGUI, vector layer selection Platform: All | Cpu: All --+- Changes (by mmetz): * status: new = closed * resolution: = fixed -- Ticket URL: https://trac.osgeo.org/grass/ticket/948#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #198: v.in.ascii: column scanning is borked
#198: v.in.ascii: column scanning is borked ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: closed Priority: critical | Milestone: 6.4.2 Component: Vector| Version: svn-develbranch6 Resolution: invalid |Keywords: v.in.ascii Platform: All | Cpu: All ---+ Changes (by mmetz): * status: reopened = closed * resolution: = invalid Comment: Replying to [comment:7 mmetz]: Still not working. Test data are LiDAR laz data available here http://liblas.org/samples/ The file I used is srs.laz [snip] # only the first 5 columns were imported It's not v.in.ascii, it's G_getl2() that fails to fetch the whole line, probably because of some obscure encoding of the output of las2txt which I am not able to figure out, or las2txt writes weird characters for empty fields. Closing as invalid. -- Ticket URL: https://trac.osgeo.org/grass/ticket/198#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] where to store GRASS settings: GISRC and wx settings
On Aug 30, 2011, at 7:48 AM, grass-dev-requ...@lists.osgeo.org grass-dev-requ...@lists.osgeo.org wrote: Date: Mon, 29 Aug 2011 22:48:53 +0100 From: Glynn Clements gl...@gclements.plus.com Subject: Re: [GRASS-dev] where to store GRASS settings: GISRC and wx settings To: GRASS developers list grass-dev@lists.osgeo.org Message-ID: 20060.2373.448470.56...@cerise.gclements.plus.com Content-Type: text/plain; charset=us-ascii Hamish wrote: ** PUT NEW DEVELOPMENT IN TRUNK AND LEAVE 6.x WELL ENOUGH ALONE +1 Can we please make an effort to finish the 6.x branch. I'd really like to see 7.0.0 released before the heat death of the universe. -- Glynn Clements gl...@gclements.plus.com +1 We should release GRASS 6.4.2 and end the version 6 series. Then we can focus on what is needed to move to an RC for GRASS 7. I don't think that there is anything in GRASS 6.5 that is not either in GRASS 6.4 OR in GRASS 7, but it is a hybrid of the two versions and this is something we should avoid because of the increasing difficulty of keeping it in sync with either 6.4 or 7. To release 6.4.2 this, we may need to roll back some in-development features like the graphical modeler and interactive cartography module that have crept into GRASS 6.4 from GRASS 7. These are really great new tools and I strongly support their addition to GRASS, but they are still in development and should not have been added to the 6.x line. GRASS 7 is a really good piece of software. But if we do not finish 6, it will never see the light of day. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] where to store GRASS settings: GISRC and wx settings
Hi, 2011/8/30 Michael Barton michael.bar...@asu.edu: To release 6.4.2 this, we may need to roll back some in-development features like the graphical modeler and interactive cartography module that have crept into GRASS 6.4 from GRASS 7. These are really great new tools and I strongly support their addition to GRASS, but they are still in development and should not have been added to the 6.x line. I think it's not good idea. wxGUI Modeler and wxGUI ps.map are not finished, but used by the user (I got several mails about the modeler) and maintained. Compared to other wxGUI components there are not significantly worse or non-functional (maybe better then others). We can marked them as experimental. We are close to 6.4.2, please don't touch anything in wxGUI, only bug-fixes are allowed. To be honest, I don't believe that 6.4.2 will the last version of 6.x. Speaking about 7.0, it will take longer time to release, we would need more active developers to cover at least basic features we would wish for G7. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] where to store GRASS settings: GISRC and wx settings
Martin Landa wrote: Speaking about 7.0, it will take longer time to release, we would need more active developers to cover at least basic features we would wish for G7. The easiest way to get more active developers for 7.0 is to cease allowing new features to be added to 6.x. Personally, I'd just kill the 6.5 branch. If something is too major to go into 6.4.x, it should be reserved for 7.0. FWIW, I don't think that fundamental changes to the raster library are feasible for 7.0. They'll just push back the release date to never. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] where to store GRASS settings: GISRC and wx settings
Hi, 2011/8/30 Glynn Clements gl...@gclements.plus.com: Speaking about 7.0, it will take longer time to release, we would need more active developers to cover at least basic features we would wish for G7. The easiest way to get more active developers for 7.0 is to cease allowing new features to be added to 6.x. Personally, I'd just kill the 6.5 branch. If something is too major to go into 6.4.x, it should be reserved for 7.0. I don't think so, just check which people are touching trunk and devbr6 or relbr64. Closing development in 6.x will not bring anyone to trunk. The real situation is that we have too few people actively developing GRASS. That's real reason why we are so behind of basic wishes we had for GRASS 7 - at least speaking about rasters, cleaning up 3d raster lib, etc. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] where to store GRASS settings: GISRC and wx settings
On Aug 30, 2011, at 1:32 PM, Martin Landa wrote: Hi, 2011/8/30 Glynn Clements gl...@gclements.plus.com: Speaking about 7.0, it will take longer time to release, we would need more active developers to cover at least basic features we would wish for G7. The easiest way to get more active developers for 7.0 is to cease allowing new features to be added to 6.x. Personally, I'd just kill the 6.5 branch. If something is too major to go into 6.4.x, it should be reserved for 7.0. I don't think so, just check which people are touching trunk and devbr6 or relbr64. Closing development in 6.x will not bring anyone to trunk. The real situation is that we have too few people actively developing GRASS. That's real reason why we are so behind of basic wishes we had for GRASS 7 - at least speaking about rasters, cleaning up 3d raster lib, etc. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa Seems an even stronger reason to focus limited development efforts on a single branch. C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] where to store GRASS settings: GISRC and wx settings
On Aug 30, 2011, at 2:45 PM, Martin Landa wrote: 2011/8/30 Michael Barton michael.bar...@asu.edu: Seems an even stronger reason to focus limited development efforts on a single branch. that's what we are more or less doing (see who commits to trunk). Anyway there is still need of fixing bugs in GRASS 6.4, improving winGRASS, preparing new release, etc. I'm completely in agreement. We should move ahead with a release cycle for 6.4.2 and get this done with. What I don't understand are never-ending discussions about what we cannot do in GRASS 6.x branches instead of discussing what should be done in GRASS 7 (including someone who will implement ideas) and motivation people to maintain GRASS 6.4 for next release (since GRASS 7 release is in the stars). I guess my suggestion would be to work on fixing bugs and finishing things in progress on GRASS 7 before adding anything else new. This is not recommending a feature freeze, but simply to get a better idea of where we are with GRASS 7. A clear roadmap would be helpful of course. Michael Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] where to store GRASS settings: GISRC and wx settings
Markus Metz wrote: In general I think it is a good idea to have all the settings and other stuff, e.g. grass-addons, sorry to complicate the discussion, but fwiw the meaning of the grass-addons dir is another unresolved issue we'lll need to deal with-- it started life as something user defined to concatenate onto $PATH, but now is also used like --prefix=, and so we have this confusing hybrid of both. in one single folder, and not scattered around. But that is a design change already implemented in grass7. Since there seems to be a majority to not introduce these changes to 6.x, I will revert the changes I did to 6.5 and also change some backports from trunk to 6.x regarding the file where wxGUI settings are stored, i.e. 6.x shall use .grasswx6 as in pre-6.4.2. to clarify what I meant why- I'm not so concerned about ~/.grasswx6, as that's quite new and not as likely to be accessed by user's own scripts, literature, experience expectations where to find things when things break (1,000 archive posts telling people to remove/edit that file if it gets broken), etc. What I am really really concerned about is changing ~/.grassrc6, which is a core file that has stood like that since 6.0, 6.2, 6.3.0, 6.4, and 'til now all our hard efforts to maintain compatibility through all the grass 6 line has been unwaivering*. [*] A notable compatibility exception was the vector/dbln file format which we necessarily had to change to allow for spaces in path names, but I think the solution we finally came to helped the transition happen without any ill effects or anyone really noticing. While not really relevant beyond the it was like that in 6.x for historical reasons understanding, fwiw I'd mention ~/.grassrc5 and for earlier grass 4 ~/.grassrc have been there since the 1990s, and perhaps the 1980s too? since stability = discipline * time, and one of our great strengths is time. whenever we cut old roots and reset that clock to 0 it's a great loss to one of our core assets. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #1430: Buffer overrun in vector/diglib dig__fread_port_L with big-endian negative values on LP64 systems
#1430: Buffer overrun in vector/diglib dig__fread_port_L with big-endian negative values on LP64 systems -+-- Reporter: rroliver | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: Component: Vector | Version: svn-trunk Keywords: diglib portable LP64 big-endian |Platform: Unspecified Cpu: All | -+-- The code in dig__fread_port_L is broken for handling big endian negative numbers on systems where sizeof(long) != PORT_LONG. Presently the code fails to negate the value and will write 4 bytes past the end of the buffer. Problem exists for all grass versions through to trunk... Patch attached (patch against 6.4.1) -- Ticket URL: http://trac.osgeo.org/grass/ticket/1430 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
