Latest Contributions by JasonTipton

‎01-31-2017

We are using a product call Epoch Field . The business hasn't fully bought into it yet, but it is an ArcGIS Runtime app and it will run on Windows/Android/iPad. It works disconnected and uses geodatabase syncing. We are still using Server 10.2 but Epoch Field works with newer versions.

‎03-01-2016

One thing was that I wanted to clarify "the wiki" as there was never a link to it and I wasn't sure what we were talking about. I believe I was agreeing with you and I never mentioned a replacement. Joshua Bixby proposed "community edition" to be part of the official documentation. I'm not exactly sure what Hannah Deindorfer was getting at, but it sounded like the community editions are Geonet, Users Conference, ArcGIS Blog (which I didn't know we could contribute to...) and "the wiki". All of this is spread out across the internet, and if you wanted an official place for that content, why not create a link from the page to a community page that others could follow the same path instead of random geonet posts. There seems to be 2 types of community content that we are talking about 1) Incorrect Documentation 2) Additional Examples/Concepts When there is incorrect documenation, it needs to be corrected in a timely manner at the official documentation, not some wiki. Even the smallest error should be fixed, not just the big ones, because the small ones that are easy for someone to figure out are big errors that could be impossible for someone else that is just learning the ESRI dance. Additionaly Examples/Concepts probably could go in a wiki/geonet post, but probably not wiki.gis.com. As for not knowing esri was behind wiki.gis.com, it's probably because that site has never been the end of a google search for the answer to a problem. I know I have ran across the site a few times before, but it has never answered a problem that I was running into so I just haven't paid it much mind.

‎02-29-2016

Hannah Deindorfer, Not sure "the wiki" qualifies as an answer to the question. The question was about product documentation. "The wiki" which I am assuming is http://wiki.gis.com/ . I didn't even know this was hosted by ESRI. The wiki seems to be what you would think of a gis wiki and reads more like an encyclopedia about gis in general rather than product documentation of a specific product/tool/api. There is 1 page devoted to python... not 1 page for every arcpy tool. There's not even 1 page on the ArcServer Rest API . . There's a link, but it's to the 9.3 documentation. If this is an acceptable place for product product documentation and examples, I would suggest putting a link somewhere at the bottom of every page in ESRI's documentation that would say "See community content". That would bring you to a page... say http://wiki.gis.com/wiki/index.php/ArcGIS_Server/10.3/Add User . If the page was empty, you could create a page and add content. Otherwise, you would see any community content that has already been added. But... I'm not sure that the wiki is the best place for detailed product documentation/examples.

‎02-29-2016

Since this isn't a class, only a script, you really don't need to put this in a method. How you did it in your original script would work just fine: # archydro variables fill_sinks = os.path.join(rasWs, "fil") flow_dir = os.path.join(rasWs, "fdr") flow_acc = os.path.join(rasWs, "fac") streams = os.path.join(rasWs, "str") stream_seg = os.path.join(rasWs, "strlnk") catchment_grid = os.path.join(rasWs, "cat") catchment_poly = os.path.join(outWs, "Layers","Catchment") drainage_line = os.path.join(outWs, "Layers", "DrainageLine") adj_catch = os.path.join(outWs, "Layers", "AdjointCatchment") If you prefer Path, just replace os.path.join(x,y,z) with str(Path(x,y,z)). Honestly, for what you are doing, I think you might have over-engineered your solution on the 2nd script. The 1st one didn't look too bad. For performance, make sure everything is working in memory like other people have suggested. Only output it to disk when you are through processing it.

‎02-27-2016

# imports at top import os import arcpy # etc. . . # define methods here def fill_sinks(): # fill sink code def flow_direction(): # flow direction code def flow_accumulation(): # flow accumulation code # etc... # write your statements inline here, and better yet test for "__main__" first # to only execute this code if you are executing this file if __name__ == '__main__' fill_sinks() flow_direction() flow_accumulation() # etc . . . I

‎02-25-2016

I misread his comment. I thought that he had moved from os.path.join to Path because he was having issues with os.path.join() and arcpy. I now see that he moved *in favor* of Path but that arcpy isn't expecting a Path object but a string. From a python perspective the Path object is an improvement because you are now dealing with a smarter object than a dumb string. The string doesn't know it is a path so you have to call some function to get the file name or directory or to append a subdirectory to the string. From looking at the methods, it looks like you can even create a directory or check if a path exists or not, all from the object itself without having to call another function. As for escape characters, it looks like it doesn't handle them unless you handle them: same as a string or os.path.join(). At the end of the day, I think you're still better off letting python add your slashes and just pass in your directory names in a list and let python make your path for you, whether that be os.path.join(a,b,c,d,e,...) or Path(a,b,c) / d / e / ... # WRONG -- Don't use \t or \a p = Path("dog\turtle\ant") p >> WindowsPath('dog\turtle\x07nt') print(p) >> dog urtlent # RIGHT p = Path("dog", "turtle", "ant") p >> WindowsPath('dog/turtle/ant') print(p) >> dog\turtle\ant # If you need to append, you are using the / operator, not the literal character '/' p / 'cat' / 'mouse >> WindowsPath('dog/turtle/ant/cat/mouse')

‎02-25-2016

As long as you always use os.path.join() and never a slash, you shouldn't have to worry about those pesky paths!

‎02-25-2016

Group all of your methods at the top under imports instead of co-mingling functions and statements. Define your variables once instead of multiple times. (flow_accumulation, flow_direction, etc) assuming they are always the same in every method. Line 98 (Script 2): It looks like you assigned flow accumulation "fac" to the flow_direction variable Don't pass RasterWorkspace into every function. Declare it once and use it inside each method. You don't really need methods. After you do the previous, the way it is currently written, you really just need print statements in between each statement letting the user know what is going on. Cutting back on recreating the same variable over and over will cut a lot of code out. These won't improve performance*, but will make it more readable, less code to manage, and less code to mess up. *It may insignificantly improve by nanoseconds by not having to re-create the same variable over and over again!

‎02-25-2016

Yeah.... I'm still on 2.7.x. What's the problem with os.path.join at 3.4? Not having 3.7 installed, but just looking through the documentation and playing around with a 3.x shell online, it seems that os.path.join returns a string object as it always has. It looks like the new pathlib is a way to store paths as objects instead of as strings so instead of having to do os.path.xyz(), you now may be able to do path.xyz. Where I'm confused is how this affects the script. At the end of the day, Peter Wilson is just formatting the path object back to a string. I don't see why os.path.join wouldn't have worked here (not that it's better than using the pathlib). Also it looks path has its own ways to concatenate paths. I went ahead and installed pathlib into 2.7. It looks like you can do this: # constructor p = Path('a', 'b', 'c') print(p) # append paths to end with the "/" p = p / 'd' print(p) print(str(p)) and it will print WindowsPath('a/b/c) WindowsPath('a/b/c/d') a\b\c Either way os.path.join str(Path) # and "{}".format(Path) should all get you to the same end goal: A string representing a path.

‎02-25-2016

There's a link at the bottom right of the page: Feedback on this topic?. I would imagine this would be the appropriate place. Not sure if they ever actually do update the docs until the next release, though. In the past, there's been no way to track the feedback like a bug, and I've never gone back to check if they actually made the changes.

Online Status	Offline
Date Last Visited	‎11-11-2020 02:23 AM

My Ideas

Latest Contributions by JasonTipton

Re: What hardware/software are your field crews using to view maps?

Re: Is there a place to send comments on the ArcGIS documentation?

Re: Is there a place to send comments on the ArcGIS documentation?

Re: Pythonic Code Structure

Re: Pythonic Code Structure

Re: Pythonic Code Structure

Re: Filenames and file paths in Python

Re: Pythonic Code Structure

Re: Pythonic Code Structure

Re: Is there a place to send comments on the ArcGIS documentation?