[GRASS-user] Change Raster Temp Directory?
Greetings, I have rasters being stored on old-fashioned spinning disks. If I could store temporary files on a solid-state drive I think the operations I am performing would be considerably faster. I see that there is a variable for specifying what temp directory to use with vector operations, but I don’t see a way to change the temp directory for raster operations. Is it possible? https://grass.osgeo.org/grass72/manuals/variables.html Thanks, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Select vector feature(s) tool sometimes selects multiple lines
Greetings, I am using the “Select vector feature(s)” tool in the g.gui wxpython user interface. Sometimes it selects more than one line, despite clicking on just one line. I assume that means that more than one line has the same category value, might that be the case? If so, can someone recommend a way to assign a unique category to each individual line of a GRASS vector? Or any suggestions on how to get the select vector features tool to only select the line clicked would be very much appreciated! Thanks, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re-projected Data Position Mismatch
> On Aug 27, 2017, at 8:54 PM, Anna Petrášová <kratocha...@gmail.com> wrote: > > On Tue, Aug 22, 2017 at 7:46 PM, Jeshua Lacock <jes...@3dtopo.com> wrote: >> >> To hopefully help troubleshoot; I just reprojected one of the raster tiles >> (from epsg: 3857), into the source location of one of the lonlat vectors >> (reverse projections from my OP), and the datasets are offset by the same >> distances. Since the dimensions of the raster are being changed (by r.proj), >> it leads me to think it must be a datum or coordinate system misalignment >> and not a projection issue. > > I have the same problem, working with NAIP imagery. It is related to: > https://trac.osgeo.org/grass/ticket/2229 > > I have to remove nadgrids: @null from the PROJ_INFO file to be able to > reproject into that location, but then it is shifted. gdalwarp helps. Hi Anna! Thank you very much for confirming that! I am working with the NAIP imagery as well. :) I have found that their original Geotiff assets work perfectly. In fact, I was very happy to stumble on to the fact that the complete NAIP archive (~250 terabytes) is available as a bucket drive on Amazon Web Services (AWS). So I setup GRASS instances to process the tiles, then download the processed, reprojected images compressed as JP2s. I am paying for the bandwidth and compute time, but I think its worth it for my purposes. I’ll be able to process and download the imagery I need in about 60 days compared to over 300 days without AWS! Cheers, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re-projected Data Position Mismatch
> On Aug 22, 2017, at 1:03 PM, Nikos Alexandris <n...@nikosalexandris.net> > wrote: > > the vector map seems to be a regular grid. If you want it to fit > exactly, can't you recreate it? Using `v.mkgrid` and cut it based on the > raster map(s) of interest? Hi Nikos, Thanks for your suggestion. It is a regular grid, but I need to look up the names of some of the rectangles (which are attributes of the grid). Also, at some point I have to get all the vector data I have to match up with the raster tiles… Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re-projected Data Position Mismatch
> On Aug 22, 2017, at 12:16 PM, Jeshua Lacock <jes...@3dtopo.com> wrote: > > and no PROJ_EPSG file exists in the Comp Location Correction; no PROJ_EPSG file exists in the rater tile location, it does exist in the Comp Location. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re-projected Data Position Mismatch
Greetings, I am attempting to merge data in a couple different projections into a single projection. But as you can see in the following image, the vector data does not align with the raster tiles. The horizontal positions match, but they don’t match vertically. http://3DTOPO.com/misalignedData.jpg I’ve never ran into this issue before using GRASS after merging countless projections together. All of the data shown in the image is in “epsg: 3857” projection, here is the contents of its PROJ_INFO file: name: WGS 84 / Pseudo-Mercator datum: wgs84 ellps: wgs84 proj: merc lat_ts: 0.0 lon_0: 0.0 x_0: 0.0 y_0: 0 k: 1.0 wktext: defined no_defs: defined towgs84: 0.000,0.000,0.000 I will refer to this location as the Comp Location. If I import a raster tile as a new location, it has this as a resulting PROJ_INFO file: name: WGS 84 / Pseudo-Mercator datum: wgs84 ellps: wgs84 proj: merc lat_ts: 0.0 lon_0: 0.0 x_0: 0.0 y_0: 0 k: 1.0 nadgrids: @null wktext: defined no_defs: defined The only difference that I can tell is that the raster tile location has a "nadgrids: @null” line which I had to delete to import the raster tiles into the first location with r.proj, the Comp Location has a towgs84 transformation (but is 0,0,0), and no PROJ_EPSG file exists in the Comp Location. Alternatively I can import the raster tiles directly into the Comp Location using r.in.gdal since the projections match (I don’t get any mismatched projection warnings). In both cases, the raster tiles are located in the same position. The PROJ_INFO file from the locations that the vector orange grid and green bounds was imported from is as follows: name: GCS_North_American_1983 datum: nad83 ellps: grs80 proj: ll no_defs: defined I had imported the orange grid and green bounds from two different locations so I could try to determine what data was in the wrong position (raster tiles or vector) but, but the both the vector layers imported are in the same lonlat projection, so I guess is wasn’t a really good test, thus I am not entirely sure which data is in the correct location. Any suggestions would be greatly appreciated. Thanks, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.out.ogr with -spat?
> On Aug 18, 2017, at 1:08 AM, Moritz Lennert <mlenn...@club.worldonline.be> > wrote: > > On 18/08/17 07:36, Jeshua Lacock wrote: >> Greetings, >> I have huge vector databases (~50 million records) that I need to export as >> many tens of thousands of tiles. >> Is it possible to use ogr2ogr’s spat argument when exporting with v.out.ogr, >> perhaps using its’ dsco or lco arguments? > > AFAIK, no. > > Seems like an interesting thing to have. Maybe you could make an enhancement > request for this in the bug tracker ? Hi Moritz, OK, thanks for the suggestion. >> Otherwise, is there a faster (more efficient) way than creating a new vector >> with v.select? v.select seems several magnitudes slower than if I export to >> a huge sqlite database and the use ogr2ogr’s -spat argument, but I would >> prefer to keep it in GRASS. > > See https://trac.osgeo.org/grass/ticket/3361 for a report of the slow > v.select. This is mostly when using the GEOS operators, not when using the > native overlap operator. Is this what you are doing ? It would be good if you > could add your experience to the above enhancement request. My apologies, I had used v.overlay, not v.select. I just tried v.select and it was very fast. Still though, I think it would be very nice to be able to specify the extents when exporting with v.out.ogr so I will make an enhancement request. Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.out.ogr with -spat?
Greetings, I have huge vector databases (~50 million records) that I need to export as many tens of thousands of tiles. Is it possible to use ogr2ogr’s spat argument when exporting with v.out.ogr, perhaps using its’ dsco or lco arguments? Otherwise, is there a faster (more efficient) way than creating a new vector with v.select? v.select seems several magnitudes slower than if I export to a huge sqlite database and the use ogr2ogr’s -spat argument, but I would prefer to keep it in GRASS. Thanks, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error in v.in.ogr with null values
> On Aug 16, 2017, at 2:41 PM, Jeshua Lacock <jes...@3dtopo.com> wrote: > >> On Aug 16, 2017, at 2:36 PM, Jeshua Lacock <jes...@3dtopo.com> wrote: >> >> #convert DBF to CSV file to properly handle blank fields >> ogr2ogr -f 'CSV' fileName.csv fileName.dbf > > Ooops - first line of the example should be this instead: > > #convert DBF to CSV file to properly handle blank fields > ogr2ogr -f 'CSV' fileName.csv fileName_fixed.dbf Doh! My mistake, please disregard this “correction”. ;) ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error in v.in.ogr with null values
> On Aug 16, 2017, at 2:36 PM, Jeshua Lacock <jes...@3dtopo.com> wrote: > > #convert DBF to CSV file to properly handle blank fields > ogr2ogr -f 'CSV' fileName.csv fileName.dbf Ooops - first line of the example should be this instead: #convert DBF to CSV file to properly handle blank fields ogr2ogr -f 'CSV' fileName.csv fileName_fixed.dbf ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error in v.in.ogr with null values
> On Aug 15, 2017, at 10:06 AM, Mira Kattwinkel <kattwinkel-m...@uni-landau.de> > wrote: > > I was able to nail it down to empty cells in the attribute table (NULL). When > filling those the error disappears. > > Have there been any changes to v.in.ogr that may cause this behaviour? Or > could this be related to OGR / GDAL? Hi Mira, I am not sure if it will work for you, but I have found that when I have empty cells, I can get around the issue by converting the file to import to CSV then back using ogr2ogr. For instance (I have only done this with shape files): #convert DBF to CSV file to properly handle blank fields ogr2ogr -f 'CSV' fileName.csv fileName.dbf #convert back to DBF ogr2ogr fileName_fixed.dbf fileName.csv #back up original DBF file before replacing: mv fileName.dbf fileName_original.dbf #then move “fixed” DBF file back to original filename: mv fileName_fixed.dbf fileName.dbf I hope this helps! Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Change SQLite DB Column Width?
> On Aug 4, 2017, at 2:03 AM, Even Rouault <even.roua...@spatialys.com> wrote: > > As column width is just a hint in SQLite and has no influence on the database > structure (you can insert fields that are longer than the declared size), you > can just edit the sqlite_master table (which is generaly a dangerous game, > and must be done only when you know what you are doing) > > With the sqlite3 shell : > > PRAGMA writable_schema = 1; > UPDATE SQLITE_MASTER SET SQL = 'CREATE TABLE > TrailSegment_12(column_definitions_before_name, NAME CHARACTER(128), > column_definitions_after_name) ' WHERE NAME = 'TrailSegment_12'; > PRAGMA writable_schema = 0; > > so basically get the existing SQL definitions of the table with "SELECT SQL > FROM SQLITE_MASTER WHERE NAME = 'TrailSegment_12'", edit it to change the > column width, and put it in the above UPDAT Hi Even, Thanks for your help. If I could figure out exactly what you mean, I think this might be the most elegant solution. But when I run: sqlite> SELECT sql FROM sqlite_master WHERE type = 'TrailSegment_12’; sqlite> It doesn’t display anything and just returns to the sqlite prompt. Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Change SQLite DB Column Width?
> On Aug 3, 2017, at 11:52 PM, Vincent Bain <b...@toraval.fr> wrote: > > to my knowledge, no way to alter a column in sqlite3 : > https://www.sqlite.org/lang_altertable.html Hi Vincent, Thanks for the verifying; I was afraid of that. ;) > .width only affects the output width of columns within sqlite3 prompt. I see, thank you. > I would suggest you to simply add a new column (with the right width), > then copy the content of the previous to the new one and trash the > former. That is a great suggestion, thank you. Is there a way to copy a column to a new column? It looks like db.copy copies a whole database, not just a column.. Will I have to use SQLite to do it? I’ve never actually used it directly before, so any examples would be greatly appreciated! Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.out.gdal to AAIGrid
> On Aug 3, 2017, at 12:24 PM, Pedro Venâncio <pedrongvenan...@gmail.com> wrote: > > I'm using r.out.gdal to export raster data from GRASS to Arc/Info ASCII Grid > format, to use in another software (Farsite). > > However, the resulting ASCII files does not have the NODATA_value parameter > in the header. > > I've tried gdal_translate and it creates, by default, NODATA_value -999 > > Shouldn't GRASS also create NODATA_valeu in the header file? Hi Pedro, Have you tried using the nodata parameter? r.out.gdal nodata=-999 input=yourFile output=yourFileOutput Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Change SQLite DB Column Width?
Greetings, I am attempting to patch vectors together with v.patch -e (I need the attributes). But I am getting this error: ERROR: Length of string columns differ Upon inspecting the columns, I see that at least one vector has a NAME column with a width of 120 characters, while most of them have a width of 80: > db.describe table=TrailSegment_12 column:NAME description: type:CHARACTER len:120 scale:0 precision:0 default: nullok:yes select:? update:? Is it possible to change the width of the columns? The DB is SQLite. I tried altering the width using db.execute and this SQL: ALTER TABLE TrailSegment_12 ALTER COLUMN NAME CHARACTER(128) But I get the errors: DBMI-SQLite driver error: Error in sqlite3_prepare(): near "TrailSegment_Michigan": syntax error DBMI-SQLite driver error: Error in sqlite3_prepare(): near "TrailSegment_Michigan": syntax error ERROR: Error while executing: 'ALTER TABLE TrailSegment_12' Seems like there must be a way. I found SQLite has a .width command, but I am not sure how to use it. Thanks, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Ann AddOns?
Greetings, Anyone know what happened to the ann add-ons? It implements artificial neural network using FANN library. The link about here: https://grasswiki.osgeo.org/wiki/AddOns Seems to take me to a german dating website or something. Which is too bad, because I think it sounds very interesting and I would like to know more about what it does or did. Anyone know where it is now? I googled for it, but mostly just find the add-on page information about FANN... Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] What does g.parser gisprompt Option Do?
Greetings, I am writing some simple parallel grass wrappers using shell scripts. What does g.parser’s gisprompt do? I looked at the documentation for g.parser but its still not clear to me. Thanks! Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Recommended v.select relate matrix?
> On Jul 23, 2017, at 7:14 AM, Stuart Edwards <sedwar...@cinci.rr.com> wrote: > > Not a trivial problem - Seems to me that there may be multiple steps > depending on the precision required. > > First, if a line starts and ends at the same place as the target line does > that qualify? - it would appear to serve as a good initial screen. If that's > too rigorous, maybe add a tolerance of +/- 10 or 100m or whatever is > appropriate for the expected precision. Hi Stu, Some lines start and end positions can vary a great deal. As shown in the first image; in the upper left corner the orange line goes well past where the purple line ends. > If there are several lines that meet this first test perhaps calculating the > distance between each of them and the target (node by node) and selecting the > one that results in the minimum cumulative distance? Is there a way in grass to select lines based on distances, or are you speaking of a possibly custom solution? > If the lines are not fully coincidental (i.e. don't start and end at roughly > the same points), some segmentation would be required so that these tests > could be applied. I tried segmenting the lines at various lengths and I actually get worse results since in some places where they overlap they are removed, but the segments that don’t overlap aren’t removed. > BTW - If it wasn't for you I doubt I would have ever have become a GRASS > user. I used your CDs with the original pre-compiled Mac binaries for a long > time in the early 2000s. Thanks for that. It's been a great ride! Hey that’s awesome! Thank you and glad to hear you are still at it! Your name actually looks familiar too. Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Recommended v.select relate matrix?
> On Jul 24, 2017, at 1:55 AM, Jeshua Lacock <jes...@3dtopo.com> wrote: > > Equals, crosses and intersects will select the line shown in red - I only > want to select the lines that are spatially similar or coincidental; the > orange lines from the purple lines. Note that I should I have said parallel instead of coincidental… ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Recommended v.select relate matrix?
> On Jul 23, 2017, at 3:47 AM, Moritz Lennert <mlenn...@club.worldonline.be> > wrote: > > On 22/07/17 23:58, Jeshua Lacock wrote: >>> On Jul 22, 2017, at 4:47 AM, Moritz Lennert <mlenn...@club.worldonline.be >>> <mailto:mlenn...@club.worldonline.be>> wrote: >>> >>> Actually I think that showing us the example with all lines will make it >>> easier to think about solutions. >> Hi Moritz, >> The purple line can select lines that just cross it like the red line shown >> in the attached image. > > But you said 'crosses' is not sufficient. Could you explain why ? Equals, crosses and intersects will select the line shown in red - I only want to select the lines that are spatially similar or coincidental; the orange lines from the purple lines. > Again, without a view of the lines you do not want to select, I'm not sure I > understand the issue. In that section, the only line that is a problem is the line shown in red. As you can see, the orange and purple lines are have similar paths, but the red line is only crossed by the purple line. It doesn’t follow the purple line… Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Workaround for pj_transform() failed: failed to load datum shift file
> On Jul 20, 2017, at 4:11 AM, Markus Neteler <nete...@osgeo.org> wrote: > > Probably it is this ticket? > https://trac.osgeo.org/grass/ticket/2229 Hi Markus, Yes; it looks like the same issue. When I googled for the issue, I came across an older different ticket for the same "failed to load datum shift file” error but I didn’t see that one. Cheers, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Workaround for pj_transform() failed: failed to load datum shift file
Greetings, Just FYI - I imported an image into it’s own location with this command: r.in.gdal input=m_4511664.jp2 output=m_4511664 location=m_4511664 In the new location: g.region rast= m_4511664; v.in.region output=bounds When I tried re-projecting the from the created location, I got this error: WARNING: pj_transform() failed: failed to load datum shift file ERROR: Unable to re-project vector map <bounds@PERMANENT> from The cause of the error was this line in the PROJ_INFO file in the location created by r.in.gdal (first command shown in this email): nadgrids: @null After removing that line, reprojection works. Cheers, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Can't use v.overlay on patched vector
> On Jul 19, 2017, at 5:07 PM, Jeshua Lacock <jes...@3dtopo.com> wrote: > > I created the location with Grass 7.2, so if it is the default, I don’t > understand why SQLite wasn’t used? Actually; correction: The location I imported the vector data into was created with GRASS 7.2 and I can see its using SQLite. The location it was projected to is using DBF. Short of creating a new location, is there a way to change it to SQLite? Thanks, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Can't use v.overlay on patched vector
> On Jul 19, 2017, at 3:58 AM, Moritz Lennert <mlenn...@club.worldonline.be> > wrote: > > That's linked to your use of the DBF format for attribute tables. Switch to > SQLite (current default). Interesting! I created the location with Grass 7.2, so if it is the default, I don’t understand why SQLite wasn’t used? Is there any documentation for switching to/using SQLIte? I looked at this page, but don’t see any information how to select what backend is used: https://grass.osgeo.org/grass72/manuals/sql.html Thanks, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Can't use v.overlay on patched vector
> On Jul 19, 2017, at 1:01 AM, Jeshua Lacock <jes...@3dtopo.com> wrote: > > I can’t seem to patch two vectors together with an attribute table then use > the v.overlay command on the patched vector. I can use v.overlay if I don’t > use v.patch's -e option, but I need the attribute table. Any way around this? I was able to get it to work by using v.db.renamecolumn to rename columns that would be duplicates when truncated by v.patch. I am kind of surprised we can only use columns with 10-characters, and using v.patch uses two of the characters (it appends a_ etc.). 8 characters isn’t exactly a lot. Is there are reason why columns have this limitation? Cheers, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Can't use v.overlay on patched vector
Greetings, I can’t seem to patch two vectors together with an attribute table then use the v.overlay command on the patched vector. I can use v.overlay if I don’t use v.patch's -e option, but I need the attribute table. Any way around this? If I run these commands: v.patch -e input=Road,Road2 output=RoadAll v.overlay ainput=RoadAll binput=bounds operator=and output=RoadAll_crop I get these warnings and error: WARNING: Database connection not defined for layer 1 WARNING: DBMI-DBF driver: column name 'a_PERMANENT_' truncated to 'a_PERMANEN' WARNING: DBMI-DBF driver: column name 'a_SOURCE_FEA' truncated to 'a_SOURCE_F' WARNING: DBMI-DBF driver: column name 'a_SOURCE_DAT' truncated to 'a_SOURCE_D' WARNING: DBMI-DBF driver: column name 'a_SOURCE_D00' truncated to 'a_SOURCE_D' DBMI-DBF driver error: Column 'a_SOURCE_D' already exists (duplicate name) DBMI-DBF driver error: Unable to create table.Unable to execute statement. DBMI-DBF driver error: Unable to create table.Unable to execute statement. ERROR: Unable to create table: 'create table RoadAll_crop (cat integer , a_cat integer, a_TEMP varchar(200), a_TNMFRC varchar(200), a_PERMANENT_ varchar(200), a_SOURCE_FEA varchar(200), a_SOURCE_DAT varchar(200), a_SOURCE_D00 varchar(200), a_SOURCE_ORI varchar(200), a_LOADDATE varchar(200), a_INTERSTATE varchar(200), a_INTERSTA00 varchar(200), a_INTERSTA01 varchar(200), a_INTERSTA02 varchar(200), a_US_ROUTE varchar(200), a_US_ROUTE_A varchar(200), a_US_ROUTE_B varchar(200), a_US_ROUTE_C varchar(200), a_STATE_ROUT varchar(200), a_STATE_RO00 varchar(200), a_STATE_RO01 varchar(200), a_STATE_RO02 varchar(200), a_COUNTY_ROU varchar(200), a_FEDERAL_LA varchar(200), a_STCO_FIPSC varchar(200), a_FULL_STREE varchar(200), a_MTFCC_CODE varchar(200), a_SHAPE_LENG varchar(200), b_cat integer )' Thanks, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.in.ogr creating unprojected location for projected SDTS DLG
Greetings, I suppose this might be a GDAL issue, but several years ago when I imported SDTS DLG data in the UTM projection it properly created a projected location. Now, running the same command(s) on the same data it creates a location that has no projection. I am importing the data with: v.in.ogr -oe dsn=dlg/BD01CATD.DDF output=dlgBD location=43115g1_dlgBD (with or without the -oe flag the results are the same) Upon examining the 43115g1_dlgBD directory, I see that no PROJ_INFO or PROJ_UNITS file is created like it used to. Examining the BD01XREF.DDF file, it states that the file is in UTM zone 11 projection (pertinent bits): UTM NAS 11 Any suggestions how to import the data into a new projected location? It seems odd that when I run: ogrinfo -so /Volumes/lilBigy/projID/43115g1/DLG/BD/BD01CATD.DDF It does not report any projection information: ERROR 4: SDTS Driver doesn't support update. Had to open data source read-only. INFO: Open of `/Volumes/lilBigy/projID/43115g1/DLG/BD/BD01CATD.DDF' using driver `OGR_SDTS' successful. 1: ABDF (None) 2: ACOI (None) 3: AHDR (None) 4: NP01 (Point) 5: NA01 (Point) 6: NO01 (Point) 7: LE01 (Line String) 8: PC01 (Polygon) Thanks, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] 7.2.0 or 7.2.1 Binaries for MacOS?
Greetings, I am having problems with the 7.2.0 version installed by MacPorts, and besides that, the main reason I am looking for other binaries is it was built without OpenJPEG support for GDAL, so I can’t open JP2 files. The KingChaos GDAL framework was built with OpenJPEG. On the main GRASS page, it states: Download GRASS GIS for Mac OS X GRASS GIS 7.2.0 (current stable) But when I click through the links, it shows: Stable Releases GRASS 6.4.6 svn GRASS 7.0.5 The only version of GRASS 7.2 is a development version getting close to a year old. So, is there a place one can download binaries of the current stable version of GRASS for MacOS? Since MacOS is the first OS listed on the main page, I would think it would be more current. Makes me think I should start OpenOSX back up and offer our old "drag a single icon to install GRASS” application (and with all the bells and whistles) again... Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Importing NAIP from WMS?
> On Jul 4, 2017, at 7:54 AM, Jeff McKenna <jmcke...@gatewaygeomatics.com> > wrote: > > Followup: I was able to get the NAIP California WMS service working with > GRASS, here were my steps: Hi Jeff, Awesome, thank you! Can you tell if the compression used is with SID? I can’t find any documentation anywhere stating what the compression used for the WMS data is. > - installed winGRASS 7.3-dev from https://wingrass.fsv.cvut.cz/grass73/x86_64/ Do you think 7.3-dev is required? I am running 7.2 and am hesitant to install 7.3-dev for a production environment. > - followed steps in the manual to execute a GetCapabilities request: > > - in "Console" tab, executed this command: > > r.in.wms -c > url=https://gis.apfo.usda.gov/arcgis/services/NAIP/California_2016_60cm/ImageServer/WMSServer? I had tried that, but I get an error: ERROR: Unable to load GDAL python bindings Anyone have any ideas how to fix this error? I am using the Mac OS X binaries installed with MacPorts. Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Importing NAIP from WMS?
> On Jul 3, 2017, at 8:57 PM, Randal Hale <rjh...@northrivergeographic.com> > wrote: > > I don't know if it would help but you can grab the NAIP from the USDA > Datagateway: https://datagateway.nrcs.usda.gov/GDGHome_DirectDownLoad.aspx > > They are SID format - so I download and uncompress them to tiff. Hi Randy, Thank you. Unfortunately the SID versions are too compressed for my needs - I am looking for the JP2 data. I got a list of all of them from the National Map, but they only have links to meta data - not the full res JP2 file. For instance: Field names: Result Number,NAIP Entity ID ,State,Agency,Vendor,Map Projection,Projection Zone,Datum,Resolution,Units,Number of Bands,Sensor Type,Project Name,Acquisition Date,Center Latitude,Center Longitude,NW Corner Lat,NW Corner Long,NE Corner Lat,NE Corner Long,SE Corner Lat,SE Corner Long,SW Corner Lat,SW Corner Long,Center Latitude dec,Center Longitude dec,NW Corner Lat dec,NW Corner Long dec,NE Corner Lat dec,NE Corner Long dec,SE Corner Lat dec,SE Corner Long dec,SW Corner Lat dec,SW Corner Long dec,Entity ID,FGDC Metadata Link,Display ID,Ordering ID,Browse Link Example record: 1,M_4012110_NE_10_1_20120720,CA,USDA,USDA-FSA-APFO,UTM,10N,NAD83,1.000,METER,4,CNIR,201204_CALIFORNIA_NAIP_1XM_CNIR,2012/07/20,40∞50'37.60"N,121∞46'52.35"W,40∞52'42.79"N,121∞48'58.02"W,40∞52'40.09"N,121∞44'42.14"W,40∞48'32.38"N,121∞44'46.81"W,40∞48'35.08"N,121∞49'02.42"W,40.843,-121.7812082,40.8785527,-121.8161166,40.8778027,-121.7450388,40.8089944,-121.746336,40.8097444,-121.8173388,71275,http://earthexplorer.cr.usgs.gov/metadata/fgdc/5280/71275,M_4012110_NE_10_1_20120720,71275,https://earthexplorer.usgs.gov/browse-link/5280/71275 I would be able to walk a directory, but they don’t allow access to view them, and I can’t find a way to create a bulk download request with the National Map (as far as I can tell you have to add each page of results to the download cart). Best, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Importing NAIP from WMS?
Greetings, Is it possible to import NAIP data using the USDA WMS server with r.in.wms? Instructions how to use their WMS server is here: https://www.fsa.usda.gov/Assets/USDA-FSA-Public/usdafiles/APFO/2013_apfo_web_service_931.pdf To download the NAIP for say California, its not clear to me what to specify for the layer(s) name(s). Whatever I have tried I get a message: "Unable to import pyGRASS: grass_gis.7.2.1 not found.” I’m not sure if that has anything to do with not being able to get any data to download or I just don’t know what I am doing. Thanks, Jeshua Lacock Founder/Engineer <3DTOPO.com> GlassPrinted.com ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Matching Histograms for Aerial Photography?
Sorry for the duplicate; I posted the other message after waiting over 6 hours for this message to post (which ultimately took about 24 hours). ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] 7.0.0 Mac OS X Install Notes
Greetings, I noticed the following minor issues while installing GRASS 7.0.0 on Mac OS X. While they are not any obstacles for me, it may block some others from a smooth installation. Therefore I would recommend adding a the following notes to the install page (http://grassmac.wikidot.com/frameworks). 1. The install page does not link to the PROJ or UnixImageIO Frameworks: http://www.kyngchaos.com/files/software/frameworks/PROJ_Framework-4.8.0-1.dmg http://www.kyngchaos.com/files/software/frameworks/UnixImageIO_Framework-1.5.0.dmg 2. The order of the install packages for some of the packages is important. It may be nice to list the order in which to install the frameworks (perhaps order the list?) 3. Following successful installation of the GRASS-7.0.pkg the installed directory permissions are set that a user cannot open the folder until changing the permissions from: drwx-- 3 503 wheel102 Feb 22 14:09 GRASS This can be resolved by adding “sudo chmod -R 755 /Applications/GRASS” (or similar) the the package installer postflight script. Thank you so much for all the development over the decades GRASS GIS Team! Cheers, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] 7.0.0 Mac OS X Install Notes
On Feb 22, 2015, at 8:50 PM, Michael Barton michael.bar...@asu.edu wrote: I don't know why Jeshua wrote to you since I maintain the wikidot site. Hi Michael, To be clear, I didn’t write to William, I wrote to the list to which he replied. As for the other issues, I'll respond 1. There IS a link to the Kyngchaos frameworks page in the menu on the right side that shows up on every page. On that frameworks page, it is clearly stated that PROJ and UnixImageIO are a part of the GDAL Complete package 2. AFAIK, the order of installing the main frameworks packages makes no difference. The ones for which order matters are included in GDAL Complete. If I am wrong here, please let me know and I will put a note on the site. On the main download page it does not state anything about installation order. I did not install GDAL first. Then I got several other errors. If it happened to me, I can only assume it will happen to others. I am just throwing out a couple super simple steps that might make ones experience more pleasant - or with the permissions issue keep them from being able to use it at all. 3. No one has ever reported this permissions issue so far. I don't know what is causing it in this case (unless it is new for 7.0 stable). AFAIK, the only permissions issue is the need to have a writeable director called bin inside the GRASS folder if you are installing extensions. This is a weird quirk of the extensions build system on the Mac. If there is a new permissions issue for 7.0 stable, it needs to be reported. But I have built it in exactly the same way as I've built all other builds recently. It has actually happened with the betas for me I just neglected to report it. As it is, the package leaves a folder that the user will not have permission to access. This should not be a difficult thing to reproduce or fix. I would suspect that the folder is owned by root because root permissions are required to install, and you likely just need to clean up the permissions as I suggested. Good news is your package can be fixed without even rebuilding the package - just take a look at the postflight script. Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] 7.0.0 Mac OS X Install Notes
On Feb 22, 2015, at 9:22 PM, Michael Barton michael.bar...@asu.edu wrote: To help me understand, I have a couple of questions below. As for the other issues, I'll respond 1. There IS a link to the Kyngchaos frameworks page in the menu on the right side that shows up on every page. On that frameworks page, it is clearly stated that PROJ and UnixImageIO are a part of the GDAL Complete package 2. AFAIK, the order of installing the main frameworks packages makes no difference. The ones for which order matters are included in GDAL Complete. If I am wrong here, please let me know and I will put a note on the site. On the main download page it does not state anything about installation order. I did not install GDAL first. Then I got several other errors. If it happened to me, I can only assume it will happen to others. Do you mean you had problems because you installed GRASS before the frameworks or because you installed other frameworks before GDAL Complete? The latter. I installed GRASS last. 3. No one has ever reported this permissions issue so far. I don't know what is causing it in this case (unless it is new for 7.0 stable). AFAIK, the only permissions issue is the need to have a writeable director called bin inside the GRASS folder if you are installing extensions. This is a weird quirk of the extensions build system on the Mac. If there is a new permissions issue for 7.0 stable, it needs to be reported. But I have built it in exactly the same way as I've built all other builds recently. It has actually happened with the betas for me I just neglected to report it. As it is, the package leaves a folder that the user will not have permission to access. This should not be a difficult thing to reproduce or fix. I would suspect that the folder is owned by root because root permissions are required to install, and you likely just need to clean up the permissions as I suggested. It does not require root access to install, just administrator access. Sorry for the oversimplification; thats what I meant. Which is the folder lacking permissions? /Applications/GRASS? Correct, here are the installed permissions: drwx-- 3 503 wheel102 Feb 22 14:09 GRASS Is this perhaps a function of the new feature in OSX that puts roadblocks for running things not downloaded from the app store? No, I don’t get a security warning. That folder just needs permissions set to 755 or similar at the end of the install… Sorry for not mentioning sooner. Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] 7.0.0 Mac OS X Install Notes
On Feb 22, 2015, at 5:17 PM, William Kyngesburye wokl...@kyngchaos.com wrote: PROJ and UnixImageIO are a part of the GDAL Complete package. Once that is installed (it is the first listed, though order is not specified), the others can be any order. Hi William, I see; even thought it is listed first it might me nice to noting install GDAL first. I recall seeing more than one type of dependency message, but I certainly could be wrong. Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Large Grass Raster Notes
On Jan 20, 2015, at 12:04 PM, Vaclav Petras wenzesl...@gmail.com wrote: Correct: g.remove ... pattern=landsat_* Incorrect: g.remove ... pattern=landsat_* The later will transform the command line to: g.remove ... pattern=landsat_01 landsat_02 landsat_03 landsat_04 ... So I just checked, and indeed I hadn’t used the quotes when it didn’t work, so thank you very much for the pointer! Since that is indeed the case, it would be super nice to add a pattern flag to r.patch and v.patch. Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Large Grass Raster Notes
On Jan 17, 2015, at 8:04 PM, Jeshua Lacock jes...@3dtopo.com wrote: maybe silly question regarding g.remove, have you used the pattern option instead of the name option? Hi, Thank you for your suggestion Anna! Well I didn’t want to use wildcards because one little mistake and — The list was verified first by eye. Besides that, this same potential issue applies to many modules that may not have pattern matching that I might be more comfortable with then essentially rm -R. Actually, I misspoke, the wildcard will not work with long lists either as it will crash with some kind argument too long message as well. Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Large Grass Raster Notes
Greetings, In the event my experience working with rather large GRASS rasters may be useful, I thought I would share it. The following notes were compiled running the GRASS 7.0.0beta4-141230 package on Mac OS X 10.10.1. The system is a 6-core Xeon with 32GB of RAM, running in full 64-bit mode. 1. Using an r.external virtual mosaic as the input proved impossible trying to run r.resample on it on trying to produce a nearly teracell raster (I ended up breaking sub-tiles). I closely followed the instructions on the Wiki. 2. On smaller sub-tiles of said image, r.resample was insanely slow even with the external imagery. At first I thought it was a limitation of being overwhelmed with small sector requests and purchased a terabyte SSD, copied the external imagery to the SSD, but that didn’t noticeably help. Throughput was way less than 1mb/sec. 3. g.remove is unusable for long lists. Actually applies to I think any utility that takes a list for input. I wish I could just put it to a file so it could parse it line by line (As I understand the issue it is a limitation of the insanely long shell arguments). If anyone wants me to elaborate on anything, or has pointers how to do things better - please let me know! Cheers, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Large Grass Raster Notes
On Jan 17, 2015, at 8:00 PM, Anna Petrášová kratocha...@gmail.com wrote: maybe silly question regarding g.remove, have you used the pattern option instead of the name option? Hi, Thank you for your suggestion Anna! Well I didn’t want to use wildcards because one little mistake and — The list was verified first by eye. Besides that, this same potential issue applies to many modules that may not have pattern matching that I might be more comfortable with then essentially rm -R. Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Remove me from the Listserve
On Jan 12, 2015, at 2:32 PM, Ben Winnick benwinn...@gmail.com wrote: Please remove my email address from this list. Hi Ben, Click on the link at the bottom of your post: http://lists.osgeo.org/mailman/listinfo/grass-user Then enter your email address in the bottom field and click “Unsubscribe”. I hope that helps. Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Virtual Mosaic import with r.external
On Dec 26, 2014, at 2:54 PM, Markus Neteler nete...@osgeo.org wrote: I suppose that would apply to r.external.out as it seems to be related to the creation of GeoTIFF (see http://www.gdal.org/frmt_gtiff.html). Hi Markus, Excellent, thank you for the tip! Note I tried again using r.patch.many with a smaller batch last night (333 billion pixel mosiac) and it ran *much* better, but I think it is stuck now. Here is a screen shot when it was cranking away: http://3DTOPO.com/r.patch.many.1.png The “Bytes Read” has been going up continuously for the r.patch processes, but the bytes written hasn’t changed in over 8 hours and appears stuck at 57%. I think I can use r.patch.many for the job but I will have to break it into smaller sub-mosiacs first. http://3DTOPO.com/r.patch.many.2.png If I understand importing a virtual mosaic correctly, I suspect using r.external with a virtual mosaic is the best way to accomplish the task at hand, but I welcome any advice! Thanks again, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Virtual Mosaic import with r.external
Hello, I was following along the Large raster data processing wiki with great interest: http://grasswiki.osgeo.org/wiki/Large_raster_data_processing My question is, when tiles are merged in GRASS using a virtual mosaic created with gdalbuildvrt, will transparent map collars be preserved? I see the man page for r.external talks about the requirement to build a mask or use r.mapcalc, but I don’t understand how I would apply that to a virtual mosaic. Is it possible? Would a certain file format handle transparent border collars better than others? Note that I already have all my tiles as GRASS rasters in my current location, alas I tried using r.patch running in parallel for the job first but it pretty much choked on the task. My attempt was terminated due to a power outage after running several weeks trying to create around 0.5 terrapixel mosaic. Any suggestions how to best build a mosaic would be super appreciated! Thanks, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Virtual Mosaic import with r.external
On Dec 24, 2014, at 5:10 PM, Jeshua Lacock jes...@3dtopo.com wrote: I was following along the Large raster data processing wiki with great interest: My question is, when tiles are merged in GRASS using a virtual mosaic created with gdalbuildvrt, will transparent map collars be preserved? I see the man page for r.external talks about the requirement to build a mask or use r.mapcalc, but I don’t understand how I would apply that to a virtual mosaic. Is It appears that GDAL_TIFF_INTERNAL_MASK may be just what I need to use. I wonder if that option is respected using r.external? Thanks! ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] units used in r.stream.distance
On Dec 16, 2014, at 9:20 AM, Margherita Di Leo direg...@gmail.com wrote: what are the units used to calculate distance with r.stream.distance in geographic (latlon) locations? As far as I know, latlon locations use latlon for the unit of measurement as well. Note that you can inspect what units you are using by opening up the PROJ_UNITS located inside the GRASS location, or display them with “g.region -p Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] DTM/DEM to TIN
Hi Giovanni, A module for this would be really neat! I am not sure if this will be helpful, but here is what I have done in the past. Set your region of interest of course. My notes indicate that I had to add an extra unit to the north and west region (not sure why). r.out.vtk -v input=dem@PERMANENT output=dem.vtk elevation=dem@PERMANENT # 'preserve normals' option kills Meshlab with DEM! r.out.vtk -v input=dem@PERMANENT output=dem.vtk elevation=dem@PERMANENT I then open dem.vtk in Paraview, and run the Delaney 2D filter (default options) save as .PLY file. Next I open the resulting .PLY file in Meshlab and run Quadric based edge collapse strategy - specify desired triangles, preserve normals and I save as .OBJ file. For my needs I choose Preserve boundary of mesh”. Cheers, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] No incltree created warning importing .jp2 files
On Dec 2, 2014, at 8:05 AM, Markus Neteler nete...@osgeo.org wrote: On Tue, Dec 2, 2014 at 4:57 AM, Jeshua Lacock jes...@3dtopo.com wrote: Greetings, I am importing thousands of .jp2 images in with r.in.gdal and creating new GRASS locations (-e). Source is NAIP. Occasionally I am seeing this what is apparently a jpeg2 warning: WARNING: No incltree created. And I was just wondering if it was any cause for alarm. And information is greatly appreciated! Putting the error message into a search engine shows that also others seem to get this error, eg http://www.imagemagick.org/discourse-server/viewtopic.php?t=25556 So it will be format related (GRASS simply calls GDAL to get the job of reading/writing done). Hi Markus! Thank you for the link, I had read that others before posting but I was not able to find what it might mean for r.in.gdal. I guess I will have to examine some of the imagery that generated the warnings, but obviously it would be better if I knew I could safely ignore them versus looking through hundreds of billions of pixels for a handful of pixels that could be bad or something. And even if some pixels are bad - I am not sure I would even be able to tell. Anyways, that is why I posted my question here and not on a JPEG forum or something. Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] No incltree created warning importing .jp2 files
Greetings, I am importing thousands of .jp2 images in with r.in.gdal and creating new GRASS locations (-e). Source is NAIP. Occasionally I am seeing this what is apparently a jpeg2 warning: WARNING: No incltree created. And I was just wondering if it was any cause for alarm. And information is greatly appreciated! Thanks, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.patch.many with GRASS 7 b3?
Greetings, I noticed that Hamish’s r.patch.many script is absent in the GRASS 7.0b3 repository. I took a look at the script and it just runs r.patch in the background for the number for cores set, so it seems like it should be fine with GRASS 7, but if someone could confirm that I would appreciate it. Thanks, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch.many with GRASS 7 b3?
On Nov 30, 2014, at 3:49 PM, Anna Petrášová kratocha...@gmail.com wrote: On Sun, Nov 30, 2014 at 5:17 PM, Jeshua Lacock jes...@3dtopo.com wrote: I noticed that Hamish’s r.patch.many script is absent in the GRASS 7.0b3 repository. I took a look at the script and it just runs r.patch in the background for the number for cores set, so it seems like it should be fine with GRASS 7, but if someone could confirm that I would appreciate it. Just by looking at it, it probably should run. If you run it on beta3, you'll be fine, with newer versions, g.mlist and g.remove were merged into g.list and g.remove, so just remove the 'm' and it should work. Great, thanks for the information! I sure wish there was a similar script for r.in.proj - I am currently reprojecting 40,000+ tiles on 6-core machine, with 5 cores sitting idle. ;) Thanks again, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch.many with GRASS 7 b3?
On Nov 30, 2014, at 4:08 PM, Anna Petrášová kratocha...@gmail.com wrote: That should be pretty simple, simpler than r.patch.many, you just run a certain number of r.proj processes in the background, wait and launch next processes. There is a wiki http://grasswiki.osgeo.org/wiki/Parallel_GRASS_jobs but perhaps someone has already a simple template in bash you could use. Wow - thank you so much! I almost didn’t even mention it - but now I have all 6 cores lit up!!! Thanks again, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
