Re: [GRASS-dev] Proposal for GSoC idea on INSPIRE
On 28/01/14 17:30, Vaclav Petras wrote: On Tue, Jan 28, 2014 at 11:12 AM, Moritz Lennert mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be wrote: On 28/01/14 16:00, Margherita Di Leo wrote: Hi All, I'd like to bring a proposal for the forthcoming GSoC, that is the support for INSPIRE. This proposal is twofold, one regarding the metadata support, the other regarding the support for the data transformation to meet the inspire schema. I would like to know your opinion before drafting the idea into the trac. I'm willing to mentor for the INSPIRE POV, and since I'm working at JRC I have the opportunity to take advantage of a direct contact with the very people who are developing the Directive. Martin Landa kindly made himself available to co-mentor from the GRASS POV. +1, but I think we should aim for generic metadata handling and then allow the use of specific schemas such as INSPIRE. INSPIRE is using some more general ISO standards, isn't it? Yes, it is based on ISO 19115, but it is slightly different. My main idea is that any metadata tool should be capable of using whatever schema the user provides (possibly proposing a few predefined ones) and not hardwired to a specific schema. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Proposal for GSoC idea on INSPIRE
Hi, On Tue, Jan 28, 2014 at 5:30 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Tue, Jan 28, 2014 at 11:12 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 28/01/14 16:00, Margherita Di Leo wrote: Hi All, I'd like to bring a proposal for the forthcoming GSoC, that is the support for INSPIRE. This proposal is twofold, one regarding the metadata support, the other regarding the support for the data transformation to meet the inspire schema. I would like to know your opinion before drafting the idea into the trac. I'm willing to mentor for the INSPIRE POV, and since I'm working at JRC I have the opportunity to take advantage of a direct contact with the very people who are developing the Directive. Martin Landa kindly made himself available to co-mentor from the GRASS POV. +1, but I think we should aim for generic metadata handling and then allow the use of specific schemas such as INSPIRE. INSPIRE is using some more general ISO standards, isn't it? Correct: it is build on ISO 19100 series of International Standards. See [1]. I fully agree that the general aim should be a unified system to handle metadata (as Yann said, interchangable and exportable into online systems). As I see it, the editor should remain general, to meet the users needs. See for example Geonetwork, it's possible to add or remove fields without restriction. The INSPIRE schema is a plus for the user, meaning that there will be specific hints to guide the user, i.e. direct links with the parts of the regulation involved in the compilation of each field of the metadata (see for example [2]), the possibility to validate the metadata calling the API of the INSPIRE validator [3], etc. QGIS metatools is a nice example of such a generic tool allowing for specification of different schemas and for different outputs through the use of XSLT conversion. QGIS compatibility would be appreciated by a lot of users and it might even show the way to go. I agree. Some other thing to consider is how this metadata support would interact with existing r.support, r.timestamp etc. I remember that Yann and NikosA was talking about this in Genova in 2013. If the GSoC idea will be accepted, I'd appreciate their contribution to the discussion. [1] http://geostandards.geonovum.nl/index.php/6.4.6_ISO_19100_series_of_International_Standards [2] http://inspire-geoportal.ec.europa.eu/editor/ [3] http://inspire-geoportal.ec.europa.eu/validator2/ -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2181: v.centerpoint: Error in `v.centerpoint': realloc(): invalid next size
#2181: v.centerpoint: Error in `v.centerpoint': realloc(): invalid next size
---+
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default| Version: svn-trunk
Keywords: v.centerpoint realloc |Platform: Linux
Cpu: Unspecified|
---+
With a freshly compiled grass_trunk and freshly checked out v.centerpoint,
in the NC dataset, I get the following error when I run
{{{
v.centerpoint --overwrite input=boundary_county@PERMANENT
output=bc_centroids acenter=median
}}}
{{{
Error in `v.centerpoint': realloc(): invalid next size: 0x0159aad0
}}}
and the same with bmedian:
{{{
v.centerpoint --overwrite input=boundary_county@PERMANENT
output=bc_centroids acenter=bmedian
}}}
{{{
Error in `v.centerpoint': realloc(): invalid next size: 0x023dbad0
}}}
I do not get the prompt back in the terminal and the v.centerpoint process
is shown as 'S' in top. I have to Ctrl-C to get the prompt back.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2181
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] [GRASS GIS] #2182: v.centerpoint: no categories in output vector
#2182: v.centerpoint: no categories in output vector
--+-
Reporter: mlennert | Owner: grass-dev@…
Type: defect| Status: new
Priority: normal| Milestone: 7.0.0
Component: Default | Version: svn-trunk
Keywords: v.centerpoint categories |Platform: Linux
Cpu: Unspecified |
--+-
According to the v.centerpoint man page: If an output vector is given,
center points inherit the categories of the respective lines and areas.
But, in the NC dataset:
{{{
v.centerpoint --overwrite input=boundary_county@PERMANENT
output=bc_centroids acenter=mean
}}}
{{{
v.category bc_centroids op=report
v.category terminé. 0 features modified.
}}}
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2182
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] [GRASS GIS] #2183: v.centerpoint: category values in ascii output should include original cat values
#2183: v.centerpoint: category values in ascii output should include original cat values +--- Reporter: mlennert| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Addons | Version: svn-trunk Keywords: v.centerpoint ascii output |Platform: Unspecified Cpu: Unspecified | +--- When using v.centerpoint to print the centerpoint coordinates to stdout, cat values represent the type of point (7 = mean of area, 8 = median of area, etc). I would find it more useful if in the ascii output the cat value would be that of the original feature (just as normally foreseen for vector output of v.centerpoint) and that the centroid type was an additional column. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2183 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] [GRASS GIS] #2181: v.centerpoint: Error in `v.centerpoint': realloc(): invalid next size
#2181: v.centerpoint: Error in `v.centerpoint': realloc(): invalid next size ---+ Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Addons | Version: svn-trunk Keywords: v.centerpoint realloc |Platform: Linux Cpu: Unspecified| ---+ Changes (by mlennert): * component: Default = Addons -- Ticket URL: https://trac.osgeo.org/grass/ticket/2181#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
Re: [GRASS-dev] [GRASS GIS] #2182: v.centerpoint: no categories in output vector
#2182: v.centerpoint: no categories in output vector --+- Reporter: mlennert | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Addons| Version: svn-trunk Keywords: v.centerpoint categories |Platform: Linux Cpu: Unspecified | --+- Changes (by mlennert): * component: Default = Addons -- Ticket URL: https://trac.osgeo.org/grass/ticket/2182#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
Re: [GRASS-dev] [GRASS GIS] #2177: g.gui.animation fail to create gif
#2177: g.gui.animation fail to create gif -+-- Reporter: lucadelu | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: g.gui.animation |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by annakrat): It looks like some bug in Pillow. If you uninstall it and use PIL instead, it should work. I am not sure if someone opened a ticket for this for Pillow, I couldn't find anything. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2177#comment:3 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] Handling of Python scripts on MS Windows
Markus Metz wrote: No, there are different versions of Python 2.7, and not all work with GRASS, see e.g. ticket 2015 Any version of Python 2.7 should be suitable for GRASS. Not all versions of Python 2.7 are suitable for WinGRASS, see ticket #2150. To the extent that I can make any sense of that ticket, it appears to relate to issues caused by attempting to bundle Python. Bundling the exact same version which is installed system-wide will obviously hide some of the problems. Executing a script uses the registry associations for the script's extension. WinGRASS does not set registry associations for Python scripts, nor does it install Python system-wide. This is because we do not want to modify an existing Python installation. The registry associations are set by the Python installer. This is why you can't reasonably bundle Python. Attempting to by-pass the system's script execution mechanism (by explicitly executing Python scripts via a specific interpreter) is the cause of all the trouble. I disagree. Troubles arise if the system's interpreter, e.g. Python installed by ArcGIS, is used instead of the python version embedded in WinGRASS. Most of the troubles arise from attempting to use a mixture of a bundled version and a system-wide installation. Which wouldn't be an issue if people didn't attempt to bundle Python. -- 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] Handling of Python scripts on MS Windows
Pietro wrote: As someone who uses both ArcGIS and GRASS on windows, I see it as a bonus that the python installations are separate. I can recommend that folks in my agency install GRASS on a computer and I can assure them that it does not affect their ArcGIS installation, with it's own ESRI - specific version of python. I completely agree. Personally I see a complete isolate python installation as a plus in that case. If only such a thing were actually possible. It isn't. Because execution of scripts uses the registry, it isn't possible to control the interpreter used on a per-process basis. -- 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] Handling of Python scripts on MS Windows
Benjamin Ducke wrote: Executing a script uses the registry associations for the script's extension. This matters for using os.system(python.exe script) from within a Python script, right? No. It matters for using e.g. os.system(/path/to/script.py) from a Python script. Or system(/path/to/script.py) from a C program. Or just script.py from a .bat file. Or any other situation where you execute a script without specifying the interpreter explicitly. On Unix, the #! line at the start of the script is used to determine the interpreter. On Windows, the extension is used to look up the interpreter in the registry. -- 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] Handling of Python scripts on MS Windows
Markus Metz wrote: AFAIU, the whole discussion boils down to the question if we want to require a system-wide installation of Python with correct python file associations in the registry, potentially deactivating an existing Python installation, or not. There seems to be agreement that we do not want to modify any existing system-wide python installation. That means that WinGRASS should 1) not do a system-wide installation of Python It should not blindly replace or modify any system-wide installation. 2) not require a system-wide Python installation It needs a system-wide Python installation if Python scripts are to be first-class citizens, i.e. having the same capabilities as a compiled program. This is an OS requirement which GRASS cannot avoid. If you don't do this, WinGRASS will always be a second-class citizen compared to the real (i.e. Unix) GRASS. -- 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] change linear back to bilinear in grass7 ?
Anna Petrášová wrote: So, is there any objection to change it back to bilinear/bicubic? It was originally bilinear/cubic. The inconsistency was the reason for the original change. I don't think that (univariate) cubic interpolation is used anywhere. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GSoC idea: Testing framework
Hi all, I would like to apply to GSoC this year with the idea of testing framework for GRASS. I probably don't have to explain the need for it. Sören suggested that he would be my mentor in case my application is successful. I hope also that I will get the feedback from all developers, now or in the future, because it is crucial that GRASS developers will actually use this framework. I described the idea shortly on Trac GSoC 2014 wiki page. I plan to include more notes on separate page in next weeks but the basic idea should be clear. Some discussion is also in #2105. Perhaps, the most innovative idea is that different types of tests should be supported (e.g. Python doctest and shell scripts), although it would be always driven form Python. For example, it seems that doctest is very convenient for modules which has standard input and output (see recent doctest for r.category module). Best regards, Vaclav http://trac.osgeo.org/grass/wiki/GSoC/2014#TestingframeworkforGRASSGIS http://trac.osgeo.org/grass/ticket/2105 http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.category/test_rcategory_doctest.txt ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2114: m.nviz.image does not work on Windows
#2114: m.nviz.image does not work on Windows --+- Reporter: annakrat | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: LibOpenGL | Version: svn-trunk Keywords: m.nviz.image |Platform: MSWindows 7 Cpu: Unspecified | --+- Comment(by hamish): Replying to [ticket:2114 annakrat]: Module m.nviz.image does not create valid image file on Windows. With tif format, it crashes and with ppm it creates a file only with header. So offscreen rendering doesn't seem to work. was the wingrass version in question built with libtiff support? see lib/ogsf/gsd_img_tif.c, nothing too complicated in there. gsd_img_ppm.c is even simpler. If header part is ok but writing the rest of the ppm image isn't, perhaps gsd_getimage() is returning bad values for xsize and ysize? Has m.nviz.image ever worked on Windows? I don't know if anyone ever tested that; does saving as tiff or ppm from the G6 tcl/tk NVIZ on wingrass work? Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2114#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
Re: [GRASS-dev] moving gsoc wiki pages
On Thu, Jan 30, 2014 at 10:23 PM, Hamish hamis...@yahoo.com wrote: Hi, [sorry yahoo mail trouble making me post out of thread] please hold off on moving any historical GSoC wiki pages until further discussion. Hi, just short answer to this thread: No problem, I don't plan to move them any time soon. Vaclav thanks, Hamish ___ 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
Re: [GRASS-dev] moving gsoc wiki pages
thanks, I don't mean to slow down your good cleanup work! Mostly I'd just like to make sure the change history gets preserved and the ideas pages past student-progress pages look wonderful (and if that means using mediawiki for presenting nicely presented media, so be it), no broken links during transition between wikis, etc. Feedback from Google is that one of the most important things they look at when deciding what orgs to accept into the GSoC program each year is a high quality ideas page for prospective students. Org applications for 2014 open in 3 days, so it's a really critical time right now to get everything in order any linked-to pages well curated. cheers, Hamish On Friday, January 31, 2014 4:58 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Thu, Jan 30, 2014 at 10:23 PM, Hamish hamis...@yahoo.com wrote: Hi, [sorry yahoo mail trouble making me post out of thread] please hold off on moving any historical GSoC wiki pages until further discussion. Hi, just short answer to this thread: No problem, I don't plan to move them any time soon. Vaclav thanks, Hamish ___ 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
Re: [GRASS-dev] [GRASS GIS] #2114: m.nviz.image does not work on Windows
#2114: m.nviz.image does not work on Windows --+- Reporter: annakrat | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: LibOpenGL | Version: svn-trunk Keywords: m.nviz.image |Platform: MSWindows 7 Cpu: Unspecified | --+- Comment(by annakrat): Replying to [comment:1 hamish]: Replying to [ticket:2114 annakrat]: Module m.nviz.image does not create valid image file on Windows. With tif format, it crashes and with ppm it creates a file only with header. So offscreen rendering doesn't seem to work. was the wingrass version in question built with libtiff support? see lib/ogsf/gsd_img_tif.c, nothing too complicated in there. gsd_img_ppm.c is even simpler. If header part is ok but writing the rest of the ppm image isn't, perhaps gsd_getimage() is returning bad values for xsize and ysize? Has m.nviz.image ever worked on Windows? I don't know if anyone ever tested that; does saving as tiff or ppm from the G6 tcl/tk NVIZ on wingrass work? It worked I guess but I am talking here about off-screen rendering which is different than just exporting image with opened window with (wx)nviz. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2114#comment:2 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] [GRASS GIS] #2114: m.nviz.image does not work on Windows
#2114: m.nviz.image does not work on Windows --+- Reporter: annakrat | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: LibOpenGL | Version: svn-trunk Keywords: m.nviz.image |Platform: MSWindows 7 Cpu: Unspecified | --+- Comment(by hamish): Replying to [comment:2 annakrat]: Replying to [comment:1 hamish]: does saving as tiff or ppm from the G6 tcl/tk NVIZ on wingrass work? It worked I guess but I am talking here about off-screen rendering which is different than just exporting image with opened window with (wx)nviz. I asked because G6's tcl/tk NVIZ and m.nviz.image both use libogsf's GS_write_ppm() which calls gsd_getimage() to get the image size. I was trying to narrow down if the gsd_getimage() function was where the problem lies. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2114#comment:3 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] GSoC idea: Testing framework
Hi Vaclav, I would be interested to help for the imagery modules, Good luck ! Yann On 31 January 2014 09:23, Vaclav Petras wenzesl...@gmail.com wrote: Hi all, I would like to apply to GSoC this year with the idea of testing framework for GRASS. I probably don't have to explain the need for it. Sören suggested that he would be my mentor in case my application is successful. I hope also that I will get the feedback from all developers, now or in the future, because it is crucial that GRASS developers will actually use this framework. I described the idea shortly on Trac GSoC 2014 wiki page. I plan to include more notes on separate page in next weeks but the basic idea should be clear. Some discussion is also in #2105. Perhaps, the most innovative idea is that different types of tests should be supported (e.g. Python doctest and shell scripts), although it would be always driven form Python. For example, it seems that doctest is very convenient for modules which has standard input and output (see recent doctest for r.category module). Best regards, Vaclav http://trac.osgeo.org/grass/wiki/GSoC/2014#TestingframeworkforGRASSGIS http://trac.osgeo.org/grass/ticket/2105 http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.category/test_rcategory_doctest.txt ___ 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
Re: [GRASS-dev] Handling of Python scripts on MS Windows
(stating the obvious) The findings should be summarized in a Wiki page.. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC idea: Testing framework
Hi Vaclav, It might be interesting to look at CTest and dashboard from cmake project http://www.cmake.org/cmake/help/v2.8.8/ctest.html http://www.cdash.org/ On Fri, Jan 31, 2014 at 7:05 AM, Yann Chemin yche...@gmail.com wrote: Hi Vaclav, I would be interested to help for the imagery modules, Good luck ! Yann On 31 January 2014 09:23, Vaclav Petras wenzesl...@gmail.com wrote: Hi all, I would like to apply to GSoC this year with the idea of testing framework for GRASS. I probably don't have to explain the need for it. Sören suggested that he would be my mentor in case my application is successful. I hope also that I will get the feedback from all developers, now or in the future, because it is crucial that GRASS developers will actually use this framework. I described the idea shortly on Trac GSoC 2014 wiki page. I plan to include more notes on separate page in next weeks but the basic idea should be clear. Some discussion is also in #2105. Perhaps, the most innovative idea is that different types of tests should be supported (e.g. Python doctest and shell scripts), although it would be always driven form Python. For example, it seems that doctest is very convenient for modules which has standard input and output (see recent doctest for r.category module). Best regards, Vaclav http://trac.osgeo.org/grass/wiki/GSoC/2014#TestingframeworkforGRASSGIS http://trac.osgeo.org/grass/ticket/2105 http://trac.osgeo.org/grass/browser/grass/trunk/raster/r.category/test_rcategory_doctest.txt ___ 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 -- Regards, Rashad ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
