Latest Contributions by MarcoBoeringa

‎06-03-2012

I don't know if it has anything to do with it, but I now noticed that only when I specifically write the mask file to disk, it is properly used as a Mask environment setting. I had been using the "in_memory" option for storing the polygon representing the mask instead of physically writing it to disk. Maybe there is an undocumented limitation with using "in_memory" datasets as environment settings for analysis, and you can't use them for that directly...? Anyone else experience this issue?

‎06-03-2012

Hi all, I am trying to set some environment settings through Python. When I look in Debug mode in the PyScripter IDE at all environment variables (launched from ArcMap by right clicking the script and choosing "Debug"), I see my Extent and Mask setting correctly being applied to the GPEnvironment "env" object, the correct coordinates and path to the mask file are visible. However, when I look at the final result of a Spatial Analyst "Con" conditional operation, the resulting raster doesn't honor the Mask set for the environment in the script in which the Con command is used. According to the Desktop Help, the Con command should honor the Mask setting... In addition, the extent, when viewed in PyScripter debugging mode, of the resulting raster, is incorrect too. The extent is the extent of the original raster, not the extent set dynamically in the Python code of the script. Any clues as to why this is happening? ArcGIS 10 SP4 by the way. Marco

‎06-02-2012

Did you check out the Spatial Analyst extension? Hi Luke, Just before you posted, I found a similar topic regarding licensing of ArcGIS levels and extensions in the Desktop 10 Help: Accessing licenses and extensions in Python http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//002z0000000z000000 Like you suggested, I did not check out the Spatial Analyst extension, as I wasn't aware I needed to do this. I now changed the code with help of the examples, and it works properly! I can see the Raster object listed now in PyScripter's debugging mode and variables window. Very nice and useful. Thanks for the response. Marco

‎06-02-2012

Hi all, Just starting with Python, I now decided it was time to see if I could get debugging functional in a Python IDE, to ease coding and debugging. Since I couldn't get PythonWin to function as a debugger for ArcGIS, even after specifically setting it as the debugging application in ArcGIS 10's Geoprocessing Options, I decided to download PyScripter instead, as I saw it mentioned on another forum. That works! I could get it launched from ArcGIS by right clicking a script and choosing "Debug". It properly loads and executes and nicely shows all content and properties of the variables and functions used in the script. However, as soon as I use a Spatial Analyst command (which is licenced, and I have run the same script successfully from ArcGIS), the debugger stops at that point stating "The tool is not licensed" as visible in the PyScripter "Python Interpreter" window. Is there anything else I need to do to make an external Python IDE like PyScripter aware of available licenses on extensions like Spatial Analyst? Any specific settings to be made or arcpy modules to import??? Any suggestions welcome! Marco

‎05-21-2012

Thanks Curtis, this is very useful information, certainly a help for future development with ModelBuilder.

‎05-21-2012

This is the way to do it. It seems elaborate but there is no other way as ModelBuilder accesses those variables accessed with "%" syntax as strings -- not objects. The commas separating arguments is python syntax, there is no way around that. Thanks Curtis, it is appreciated. This is a clear explanation, and I was suspecting something like that. As I am just starting with Python, it is all a bit new to me and getting to know these specific issues and how to handle them, takes time. The way this all works is the the input expression to Calculate Value is interpreted by model builder (variables substituted in) -- and the resulting function is then passed to python literally. This is the same reason that pathnames must be used with Calculate Value like this: def func(r"%mbuilder path variable%") Hope this helps! Could you elaborate a bit more on this specific subject regarding pathnames? I haven't read about it before. And is the "r" before the inline variable a typing error, or does it need to be there?

‎05-20-2012

The error is in the incorrect usage of Python's "rstrip" command. "rstrip" removes ANY occurrences of the characters in the search string you supply (in your case "_shp") from the right side of the processed string. This is why it is going wrong, since "citiespop_shp" contains an additional "p" character as the ending, and since "p", is part of "_shp", it is also removed from "citiespop", resulting in "citiespo". The removing only stops at the "o" character ("citiespo"), as that is the first character not part of the search string "_shp" Please note that for "rstring", the order of the characters you supply is irrelevant. If you coded: "teststring.rstring("phs_")" the results would be exactly the same, e.g. giving you "citiespo" for the processed basename "citiespop_shp" You will need to use another of Python's string commands to accomplish what you want to do.

‎05-19-2012

Hi all, For the record: ArcGIS 10.0 SP4. Just getting my feet wet for the first time with more advanced ModelBuilder techniques in combination with Python, I noticed there is a possible issue / bug with the in-line variable substitution in non-English locals. My computer is set to Dutch, and displays "," as the decimal point character. However, if I have a numeric variable with a decimal point in it (in my case the values were Double), think of "1234,56789", the in-line variable substitution leads to a fault as soon as the variable is inserted in a Python function's argument list, as Python uses the comma "," character to separate out different arguments. I saw this issue popping up when I tried using two Double variables as arguments in the Calculate Value tool of ModelBuilder. See the attached screenshots. The first screenshot shows the original Python code I inserted in the Calculate Value tool. This code returned the error seen in screenshot 2. Notice it clearly states that the "getMBRsqrt" function I defined "takes exactly 2 arguments (4 given)" while 4 given!. Also look at the string of numbers in the red lettered error description. It shows the two variables I passed also being separated by the decimal comma of the values themselves, causing 4 "pseudo arguments" to be passed over to the function, instead of two numbers using decimal points. This is of course wrong, and leads to the fault, as my function only accepts two arguments and must have the decimal values / doubles passed over. Only when I elaborately changed the function, and passed the variables as strings, converting them back to numbers, could I run it. See screenshot 3 for the modified code in the Calculate Value tool that did run properly. Before I needlessly start reporting this to ESRI, can someone else confirm this issue? I tried finding it in the list of fixed issues for SP5, but no such issue seems listed for fixing. Marco

‎05-16-2012

Getting good at geostatistical modeling requires study, practice, and often a bit of luck. X2. I think many people underestimate the need to delve in these kind of subjects, whether it's geostatistical or plain statistical modelling on numbers. There is a lot going wrong in practice, and unfortunately also many datasets not only misinterpreted, but often under-used because people don't know what to do with it to get interpretable results. If you read the help and decide you want more information, a colleague published a book last year on performing spatial statistics (and geostatistics) in ArcGIS: http://esripress.esri.com/display/index.cfm?fuseaction=display&websiteID=194 Don't forget this small but helpful introductory whitepaper by the same author: http://www.esri.com/library/whitepapers/pdfs/intro-modeling.pdf

‎05-12-2012

Can't answer your question as I haven't tried what you are attempting, and you probably already read it, but this ESRI PDF gives some more details, see point 5... Maybe there is a limit to the number or Feature Datasets open for editing (just 1 allowed??). E.g. you are not allowed to make two Feature Classes in two different Feature Datasets editable, but are allowed to edit one Stand-alone (not in Feature Dataset) Feature Class, and one residing in a Feature Dataset...? Just guessing here.

‎05-12-2012

OK, I now discovered more or less what and where is actually going on. While ArcMap only shows a progress bar for a few minutes, the unaccounted time afterwards is spend writing classic ESRI grid format files in the Windows user profile's Temp directory. I can see ESRI grid files being build up (file size increases) in cryptically named subfolders. Seems the processing needed for a fill are far from over when ArcMap stops showing progress. Frustrating. It is still unclear exactly what is going on. I know the Help states Fill is the equivalent of a number of tools combined. "The Fill tool uses the equivalents of several tools, such as Focal Flow, Flow Direction, Sink, Watershed, and Zonal Fill, to locate and fill sinks.", so I wonder if ArcMap is just combining the outputs of these processes, or is really "filling up" / replacing sinks with hydrologically corrected DEM values. Whatever, I am glad it is now doing it on an external SSD, and not my harddisk, because it is literally writing Gigabytes of grid data on end to the Temp and subsequently removing files again.

‎05-12-2012

Hi all, Has anyone else noticed this: when I run the Fill tool to remove spurious sinks in my raster DEM, ArcMap and the Fill tool seem at first to be working quite fast, 0-100% in limited time, in consecutive iterative runs to properly fill the sinks. However, after seeing the 0-100% progress bar fully finish 3x times or so (or as much as the iterative process of filling needs), ArcMap than fails to add the created DEM. Instead, it starts pounding away like crazy on the harddisk, in a kind of activity you really do not want on a hard drive but only in RAM or on a SSD as it will wear out a hard disk fast, and only adds the final result a very long time after the progress bar of the Fill tool disappeared. So it does finish, but maybe an hour or so after the five minutes Fill tool processing as displayed by the progress bar. I noticed the final processing of the raster takes place in your Windows users accounts "Temp" directory, as I can see activity going on there related to ArcMap. I am fully aware that the fill process is an intensive one, but this seems wrong. It seems like ArcGIS needs an excessive amount of time to write the final result. I realize the fill tool needs to update the existing grid in specific locations, and I begin to wonder if that is the issue??: ArcMap trying to write a raster in a kind of extremely inefficient database SQL Update statement, replacing records in a file geodatabase raster table instead of just dumping a whole new raster table in the file geodatabase that is my final destination location for the result... Anyone else notice the same issues with the Fill tool? Marco

‎05-11-2012

Hi Marco, You could try the Tiled Labels To Anno tool or export using Data Driven Pages - either way a new labelling run takes place for each extent so you should see every feature labelled when you zoom in. Thanks Jon, that is a useful tip and good addition to this thread. I am already setting up Data Driven Pages and determining which labels I would like to have tiled, if not all. Of course, if you already have a fully annotated layer stored in an Annotation feature class, and disabled "Label features" for the corresponding layer, the Data Driven Pages will not solve the issue. That is just one minor caveat to that solution, it needs active labeling set.

‎05-04-2012

OK, well, I think I now figured it out myself... 🙂 what I hadn't reckoned with, is that when using normal labeling, the labels are actually only placed within the visible extent of the data frame on the layout. That is good for display, as labels are not "cut off" at the borders of the data frame on the layout, but it also means that when exporting annotation to an Annotation feature class, where you would usually want to export the entire feature class so as to support panning across the entire dataset and still see labels, labels may be placed OUTSIDE the current view if there are long lines like roads. Hence they are not visible in the same way as with normal labeling... You can solve this by choosing "Only label current extent" in the export options for "Convert Labels to Annotation", but this also means the exported annotation will not cover the entire dataset. Seems we have a trade off here: either label only "Features in current extent" when exporting to annotation to get consistency between the dynamic labeling and annotation, but with the drawback of not being able to pan your entire dataset with annotated labels, or label using "All features" when exporting to annotation, but risk labeling to be different from what the current extent of the data frame in layout view shows... Food for thought... :confused: *** EDIT ***: this also opens up another possibility/ solution: If you have an already predefined set of extents for which you want to make maps, like 5 regions (not necessarily equal in size like a regular map grid!), you could simply create a (poly-)line feature class of the outlines of the regions and add it to the view. Set it to be high "Feature Weight" so as to enforce that the features may not be overlapped by labels. Set other labeling lower weight. This is what happens at the borders of a data frame in layout view. And set symbology to 100% transparent so as to hide it's existence. You probably need to enable labeling as well for the labeling engine to have it participate in the labeling process. Maybe you need to set labels as well to transparent. You now have a dataset that will at least enforce that created annotation during export to the geodatabase will hopefully not overlap / be cut off at borders, and more or less confine itself within the polyline feature. It is not entirely the same as the dynamic labeling, but it might help in some cases (I haven't tested this thought yet though!). I also see now that using so called "Map document Annotation" might be better suitable for my purposes. Have to read a bit more though about that and annotation groups.

‎05-04-2012

Hi all, I am having an issue with the "Convert Labels to Annotation". For the record: - WinXP SP3 - ArcGIS 10.0 SP4 - ArcEditor with just the basic labeling engine, so no Maplex. I would like to setup a number or Annotation feature classes in my FGDB. I spend a lot of time tweaking cartographic display including the usage of symbol levels on road and city feature classes, but also setting up labeling rules, including setting up individual labels classes for each type of road or town as part of the settings of the Data Frame and layers. I set Feature Weights and Labeling Weights, labeling priority etc and when I view the labeling result using just the normal labeling option (right click layer and choosing "Label Features"), everything looks fine and how I want it. The results of the labeling settings and layer order in the TOC seem to be considered well. However, as soon as I attempt to export the exact same labels to my FGDB using the "Convert Labels to Annotation", I notice I get a different result. Labels that should have been placed with high priority, e.g. the town names, are missing in the view. The final result is not what I want and not consistent with the normal labeling. It seems the "Convert Labels to Annotation" tool ignores settings, or doesn't apply them in the right order. Anyone else experiencing similar issues or having tips how to resolve this? Marco Boeringa

Online Status	Offline
Date Last Visited	yesterday

My Ideas

Latest Contributions by MarcoBoeringa

Re: Environment settings ignored when set through Python?

Environment settings ignored when set through Python?

Re: "Tool not licenced" while debugging in Python IDE

&quot;Tool not licenced&quot; while debugging in Python IDE

Re: Please confirm: Possible BUG with in-line variable substitution and decimal point

Re: Please confirm: Possible BUG with in-line variable substitution and decimal point

Re: Batch Copy Shapefiles to Geodatabse: How to improve current script

Please confirm: Possible BUG with in-line variable substitution and decimal point

Re: Kriging Cross Validation Approaches

Re: File geodatabase, concurrent editor

Re: Fill tool taking forever to complete after processing is done.

Fill tool taking forever to complete after processing is done.

Re: "Convert Label to Annotation" gives different result than normal labeling?

Re: "Convert Label to Annotation" gives different result than normal labeling?

&quot;Convert Label to Annotation&quot; gives different result than normal labeling?

Re: Hinduja Swiss (Switzerland) IT-Professional-Ho...

Re: Issues with Editors using the new threading op...

Re: Issues with Editors using the new threading op...

Re: Issues with Editors using the new threading op...

Re: Issues with Editors using the new threading op...