|
IDEA
|
Andrew, Have you, or haven't you, tried the SQL WITH that I suggested to you? I am pretty sure this will solve your issue. I have used WITH with some pretty horrendous SQL statements in both ArcMap and ArcGIS Pro without issues. You also still haven't answered the question as to what exactly doesn't function or what (database) error you receive when using your SQL statement as part of a Query Layer's SQL. Please post the geoprocessing error or database error here (e.g. as captured screenshot by using PrtScreen and paste) instead of referring back to the Help and another example query.
... View more
07-17-2018
12:50 PM
|
0
|
1
|
4380
|
|
IDEA
|
Andrew, Have you, or haven't you, tried the SQL WITH that I suggested to you? I am pretty sure this will solve your issue. I have used WITH with some pretty horrendous SQL statements in both ArcMap and ArcGIS Pro without issues. You also still haven't answered the question as to what exactly doesn't function or what (database) error you receive when using your SQL statement as part of a Query Layer's SQL. Please post the geoprocessing error or database error here (e.g. as captured screenshot by using PrtScreen and paste) instead of referring back to the Help and another example query.
... View more
07-17-2018
12:50 PM
|
0
|
1
|
5997
|
|
IDEA
|
Yes, you definitely need to give more information as to the exact error you are experiencing. Just saying "it doesn't work" is not going to help to solve this. As to one tip though: You may also consider using the WITH "Common Table Expression" construct in your SQL. This doesn't require the right to create views in your database, yet still achieves something close to it, causing the database to create a kind of temporary table that should act much like the view you may need. SQL WITH: Organize Complex Queries
... View more
07-13-2018
12:36 PM
|
1
|
1
|
4380
|
|
IDEA
|
Yes, you definitely need to give more information as to the exact error you are experiencing. Just saying "it doesn't work" is not going to help to solve this. As to one tip though: You may also consider using the WITH "Common Table Expression" construct in your SQL. This doesn't require the right to create views in your database, yet still achieves something close to it, causing the database to create a kind of temporary table that should act much like the view you may need. SQL WITH: Organize Complex Queries
... View more
07-13-2018
12:36 PM
|
1
|
1
|
5997
|
|
POST
|
I don't know if you are a "Pro" shop only, but if you still have ArcMap installed, I strongly recommend downloading the ArcGIS Editor for OpenStreetMap, and use either the OSM File Loader (Load only) or Load OSM File tool instead of interoperability. ArcGIS Editor for OpenStreetMap: https://www.arcgis.com/home/item.html?id=0c4b24608fc94542ba5d1130c0606802 Like you, I have had bad experience with the interoperability Quick Import option. It has bugs, and forces a data model onto you that may not suite your needs. The ArcGIS Editor import tools are more flexible, especially combined with the OSM Attribute Selector tool, that lets you freely choose OSM keys to add to your feature classes after import. There are a few differences between the import tools though: OSM File Loader (Load only): - Supports the Parallel processing environment setting, meaning you can have faster import using multipe cores - Doesn't import full relation (member) data, although it will properly import routes and mulltipolygons, so still perfect for cartography - Because of the second point above, you can't use it to create Network Datasets for routing purposes - You can also not use this to edit & upload data using the Editor's OSM editing capabilities. Load OSM File: - Slower import, as it only supports single core processing - Does load full relation (member) information - Suitable to create Network Datasets for routing - Imported data can be edited & uploaded using the Editor's OSM editing capabilities, but do note that you should not attempt to edit very large imports (e.g. county / state / province / country). Editing is only supported on small datasets. I also strongly recommend you to download ready-made OSM extract from the Geofabrik website if you intend to import any significantly sized dataset. The download options of the Editor are not capable of large downloads, and you can therefor not get big extracts with them. Use the excellent Geofabrik services instead: www.geofabrik.de Unfortunately, there is currently not yet a "Pro" version of the Editor toolbox, and not even a basic importer containing the tools mentioned above. I have an open issue on Github for this, but there hasn't been progress: https://github.com/Esri/arcgis-osm-editor/issues/120 Let your voice be heard there if you think it would be useful to have at least a conversion of these import tools to Pro. I personally have had no need for the true editing capabilities of the ArcGIS Editor, I use iD and JOSM instead, but the import tools are valuable. In addition, due to the very specific and rare compatibility with Geodatabases, the Editor's editing capabilities do not include relations, only plain ways and nodes.
... View more
07-13-2018
07:42 AM
|
2
|
0
|
1445
|
|
IDEA
|
Actually, I had two A0 posters based on my ArcGIS Renderer for OpenStreetMap up at the map gallery at NACIS 2017. One of the people speaking out his appreciation, turned out to be working for National Geographic... so I guess I already got that thumbs up ;-). As to a blog post: this is the result of four years of development and research by me personally on that Renderer, which is a combined Python / Modelbuilder toolbox that I build from the ground up as a pure ArcGIS solution for working with OpenStreetMap data in ArcGIS. Although in the most recent version I am also capable of using an osm2pgsql created PostGIS databases as a datasource, whereas I initially set out to use the ESRI ArcGIS Editor for OpenStreetMap import options to create File Geodatabases for rendering (functionality which is still there). This is, however, a project to big for a simple blog post. Stay tuned for more though... I have more plans with this Renderer!
... View more
07-06-2018
02:05 PM
|
1
|
0
|
3084
|
|
IDEA
|
A true cartographer (which I am not) will never allow software to determine label placement. I partly agree, but to dismiss automatic labeling entirely, is not the way to go. In fact, Maplex labeling, through its settings, incorporates many of the "natural" and intuitive things cartographers would do to place labels. It is to a large extend build from a "cartographers" point-of-view. The big thing though with using Maplex, is that you really need to spend time with it to fine-tune its settings and to learn how to use them effectively. That - to me - is in essence very much equivalent to "never allow software to determine label placement". You, as the cartographer, should be in charge of what Maplex does. This is by no means an easy task, just like fully manually annotating a map isn't. One reward of Maplex is though, that once you set it up appropriately, you can repeat the labeling, and process maps from all over the globe using similar settings if an appropriate global dataset is available. Here are just two examples of maps I created using OpenStreetMap data, and that heavily rely on Maplex (in fact, all labels were placed by Maplex). I spend a huge amount of time fine tuning the used labeling settings, and there are in fact hundreds of labelclasses at work here. These maps are by no means perfect, and there are definitely things one might do differently when placing labels manually, but I do think the Maplex results are by no means to be dismissed.
... View more
07-05-2018
12:29 PM
|
2
|
1
|
3084
|
|
POST
|
Ah, yes, sorry, I have been to busy with other stuff to get back on this. Yes, I did get an official response through tech support / ESRI Netherlands. It basically boils down to a confirmation of my suspicions, and especially that Pro starts to automatically calculate the spatial extent in the background, pulling all records from the database corresponding to the Query Layer's SQL statement, whenever it hasn't yet done this and it starts to be relevant to Pro. E.g. the moment a Query Layer is created or its attribute table opened. With the current implementation, this can be a hugely costly operation against (ultra) large databases and with specific queries selecting many records (or all like when dragging & dropping a database table in the TOC). They basically confirmed this observation also: "As a consequence, I am now getting convinced that the behavior I am seeing is actually NOT A BUG, but a change in how ESRI decided to handle Query Layers and specifically the calculation of the spatial extent of such Query Layer." meaning especially that ArcMap has a clear visible point in time when the Query Layer's Spatial Extent is calculated with a dialog popping up, with an override option right there in the dialog, while Pro more hides this (although you can set extent in a Query Layer's properties when the layer is already in the TOC) and has this triggered automatically in the background. Finally, they recommended to create an ArcGIS Idea for potential changes to the Query Layer handling. I have some ideas based on all of this, and indeed intend to create one when I have some time. When I do, I will post a link here for all of you to start voting it up... Last remark: I also re-discovered another Help page with an option that I didn't yet explore, but think may be of help to some and could potentially speed up especially the opening of attribute tables of Query Layer's in case of very large tables: Define parameters in a query layer—Query layers | ArcGIS Desktop I already read before about query layer parameter's but hadn't yet properly read up about the view_extent option, which seems to be a way to limit your attribute table's records to only those records visible in the current view's extent. If this functions properly, this could considerably enhance the time needed to open attribute tables of query layers based on large database tables. Of course, this only really works when being zoomed in, and you won't see all records then, but that is not really relevant in the context of >100M record tables...
... View more
07-03-2018
09:54 AM
|
0
|
2
|
2005
|
|
IDEA
|
To be honest, I think what is really needed for advanced - topographic map style - cartography is a bye-bye to dynamic labelling and styling in vector tiles, and instead introduce, at least optionally, to fully anchor each and every individual label character of a label in a vector tile, including its position, rotation, symbology (font, color, size) etc. What I am actually suggesting is a kind of "vector tile annotation", where labels and label positions are fully pre-computed and stored, as in an Adobe PDF file exported from ArcMap or Pro. This somewhat goes against the basic concepts of vector tile styling and rendering, where rendering of the labels and label placement is supposed to happen dynamically on the client. The Maplex label engine though, has so many great options that likely will never be implementable in vector tiles, it would be a shame not to be able to use it to pre-compute and place labels using it, and then subsequently export it to vector tiles knowing the positions are fully retained.
... View more
07-02-2018
01:19 AM
|
0
|
1
|
3084
|
|
POST
|
Hi James, Thanks for posting this. I can confirm your workaround seems to work. Once I manually copied and renamed the default 'arcgispro-py3' environment to my user profile, I could indeed install new packages and make the change of the environment stick in Pro, instead of being thrown back to the default environment. So I can now finally get to work. I did not remove the 'read-only' property of the folder by the way, just copied and attempted to install a new package in the copied environment. You are correct about the 'proenv.txt' being generated as well, I saw that too. I haven't tried to install the Spyder package by the way, I just need pyodbc for now.
... View more
06-28-2018
10:40 AM
|
3
|
2
|
4540
|
|
POST
|
I think some people at ESRI are working overtime right now... hope to see a fix in a 2.2.1 release soon.
... View more
06-28-2018
06:51 AM
|
1
|
0
|
4540
|
|
POST
|
@Hakon Dreyer, Please note that I already discovered one bug related to path names in the interface of the package manager of Pro 2.2, that may or may not be the root cause of this issue. I posted that with screenshots in this thread: https://community.esri.com/thread/217056-error-with-toolboxes-in-arcgis-pro-22#comment-781502 Notice how Pro omits the "_" underscore in the path of the "backup" of the Conda environment that Pro 2.2 creates upon install. I could definitely see a wrangled path causing more issues...
... View more
06-28-2018
01:09 AM
|
1
|
0
|
10914
|
|
POST
|
Dan, nothing gets "uninstalled", your old environment gets "backed up" when you upgrade to the official 2.2 release, that is exactly what the Help describes, and what I saw happening with my customized Python environment (I actually only installed one extra package - pyodbc - in Pro 2.1, and I see it listed in the "backup" copy of the old environment): The Python Package Manager—ArcPy Get Started | ArcGIS Desktop (see the "Notes") If your "2.2 beta" did not do this, than ESRI may have hastily added this inbetween 2.2 beta and the official 2.2 release, that haste might actually explain the bug being introduced... but that is just mere speculation.
... View more
06-27-2018
11:37 PM
|
0
|
0
|
4324
|
|
POST
|
Well, I guess here we have (the)/a bug: look at the two images, notice how the file path of the environment contains an underscore, while Pro omits it in its interface: @George Thompson ?
... View more
06-27-2018
11:37 AM
|
1
|
0
|
4324
|
|
POST
|
Dan: I think that is normal, the Help clearly states that the old environment is backed up with a name <OLD_ENVIRONMENT_NAME>_backup, see here:_ The Python Package Manager—ArcPy Get Started | ArcGIS Desktop "When updating from an earlier version of ArcGIS Pro, if an older arcgispro-py3 environment exists, it will be renamed to prevent overwriting. The existing environment's folder name will be appended with _backup. A new default arcgispro-py3 environment will be created and activated automatically." And if you look at the image the OP posted in that other thread you linked, you can see he has the <OLD_ENVIRONMENT_NAME>_backup visible in his package manager. I also had a look at my backup environment, and it did have the one package I installed in it. Remains the problem that you cannot even switch to the old environment, because the change / selection doesn't stick: once you open the package manager again, it is back to square one on the new - read-only - default environment. It just won't let you change the environment to anything else from the default. One interesting things though: I now notice the "backup" version lacks the supposed "_" underscore, it is listed as: <OLD_ENVIRONMENT_NAME>backup instead of <OLD_ENVIRONMENT_NAME>_backup This is not according to the Help, it should have the underscore in the name.
... View more
06-27-2018
11:32 AM
|
1
|
4
|
4324
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 01-31-2026 04:45 AM | |
| 1 | 12-08-2025 09:12 AM | |
| 1 | 12-05-2025 12:38 PM | |
| 1 | 12-04-2025 10:08 PM | |
| 1 | 12-04-2025 10:11 AM |
| Online Status |
Online
|
| Date Last Visited |
yesterday
|