POST
|
I don't think there is a parallel in MSSQL. Results are passed to clients without generating a schema in the database. I couldn't pass a query and find some log parameter that would show a schema name for my connection.
... View more
04-24-2019
02:58 PM
|
0
|
0
|
257
|
POST
|
@Colin Zwicker and Marco Boeringa I tried to split the list into two and it works (See the scripts below ). This is a workaround. if fc1234_boolean.lower() != 'true':
arcpy.AddMessage("Making selection")
for fc in inputlist:
with arcpy.da.SearchCursor(fc, ["LINK_ID"]) as cursor:
for row in cursor:
linkidList.append(row[0])
linkidList1 = []
linkidList2 = []
linkidList1 = linkidList[:len(linkidList)//2]
linkidList2 = linkidList[len(linkidList)//2:]
arcpy.AddMessage(linkidList1)
arcpy.AddMessage(linkidList2)
where1 = '"LINK_ID" = {0}'.format(int(linkidList1[0]))
del linkidList1[0]
for linkid in linkidList1:
where1 += ' OR "LINK_ID" = {0}'.format(int(linkid))
where2 = '"LINK_ID" = {0}'.format(int(linkidList2[0]))
del linkidList2[0]
for linkid in linkidList2:
where2 += ' OR "LINK_ID" = {0}'.format(int(linkid))
arcpy.AddMessage(where1)
arcpy.AddMessage(where2)
arcpy.SelectLayerByAttribute_management(streets_nav, "NEW_SELECTION", where1)
arcpy.SelectLayerByAttribute_management(streets_nav, "NEW_SELECTION", where2)
arcpy.SelectLayerByAttribute_management(ows, "NEW_SELECTION", where1)
arcpy.SelectLayerByAttribute_management(ows, "NEW_SELECTION", where2)
arcpy.SelectLayerByAttribute_management(rdms, "NEW_SELECTION", where1)
arcpy.SelectLayerByAttribute_management(rdms, "NEW_SELECTION", where2) Therefore, the feedback is: 1. With this SQL where += ' OR "LINK_ID" = {0}'.format(int(linkid)) If the record is quite large, for example in this case 6090, then the arcpy function "SelectLayerByAttribute_management" can not handle it. arcpy.SelectLayerByAttribute_management(streets_nav, "NEW_SELECTION", where) However, if the record has been splitted, then it can handle it. It is a workaround to make the tool working but I did not figure it out the reason behind it. Regards, Fengchao
... View more
12-06-2018
06:04 AM
|
1
|
0
|
1445
|
POST
|
Well, I can now answer this question myself: no, the large discrepancy is not an error or bug in the Diagnostic Monitor. I have actually been heavily underestimating the amount of memory usage of Pro and how much it can allocate under certain conditions and with large numbers of layers in the TOC of a complex map. In the attached figure, you can see Windows allocated a whopping 42.5 GB of memory, most of which is caused by Pro, which the Diagnostic Monitor shows as using close to 32 GB. This was based on a Map document with a couple of hundreds of layers connected to a PostGIS database. This is also a clear warning to all: I had been battling frequent crashes with some power usage of Pro and complex Pro Map documents with hundreds of layers, but have now realized that much of these issues have to do with Pro running out of allocatable memory. No, you don't need to have 64 GB RAM in your laptop (although it is nice to have), but I would definitely recommend anyone having an SSD of at least 256 GB, to set a swap space of 64 GB. This will make sure Pro can still run on a <= 16 GB RAM laptop or desktop, while it should not affect performance much with SSD.
... View more
10-31-2018
08:37 AM
|
0
|
0
|
558
|
POST
|
I am fairly certain I was using ArcMap 7 and up. Malcolm Meyer City of Zanesville – GIS Specialist 401 Market Street, Zanesville Ohio 43701 malcolm.meyer@coz.org<mailto:malcolm.meyer@coz.org> | 740-617-4876 www.coz.org/maps<http://www.coz.org/maps/> | www.coz.org/stormwater<http://www.coz.org/stormwater>
... View more
01-06-2020
05:55 AM
|
0
|
0
|
550
|
IDEA
|
I'm using ArcGIS and using the Cascade Builder to build a Story Map. I've previously used Story Map Journal to make story maps and in there you are able to adjust font size and apple superscript and subscript. Other than that I'm not quite sure what other details you need.
... View more
09-12-2018
10:45 AM
|
0
|
0
|
333
|
IDEA
|
ArcGIS Pro introduced a new font character related setting in Maplex labeling that is not present in ArcMap: support for substitute typographic ligatures (see image entirely below). A ligature is a combination of two letters that are more or less treated as a single character and placed at a specific distance from each other to improve legibility and typographic display. Modern fonts support the definition of substitute ligatures, where the ligature is not composed of a single specific lettercombo defined as a single character, but dynamically compiled from the corresponding letters, if I understand the Wikipedia page about ligature right. In the image below, you can see such ligature substitute being used for the "fl" letter combo. However, this is a special situation. As you can see, the label text uses the Maplex "Spread characters / letters" setting that is present in ArcMap and ArcGIS Pro. Also, the text has defined halos, but as you can see, the text halos are not using the ligature setting, as this seems not supported by the label engine. I actually filed a bug report with ESRI for this, but was told to disable the ligatures setting. Reading up about ligatures, and seeing the labeling result with the "fl" as ligature as actually being typographically erroneous when "Spread characters / letters" is selected (it displays bad if the "f" and "l" letters are not spread), I have to agree with ESRI it is better to disable ligatures if "Spread characters / letters" is selected for labeling. However, since the ligatures are by default on in Pro, this causes confusion for users, as there are now potentially conflicting settings in Maplex and Pro, that will lead to visual artifacts as shown in the image above. I therefor propose a number of possible enhancements, that could resolve this: - Enhancement request 1: Automatically deselect and disable the label class's "Ligatures" setting in ArcGIS Pro if a user selects "Spread letters up to a fixed limit" or "Spread letters to fill feature" in the label class's "Position/Spread Labels" setting, as these two options are essentially technically, as well as cartographically / typographically, incompatible (and will cause a visual defect if the font has halos, as halos don't support ligatures and will thus not line up with the true label text). *NOTE(!)*: This setting should also be disabled when importing or opening an ArcMap *.lyr file having the corresponding "Spread characters" setting enabled on a label class, or when importing an ArcMap document in Pro (*.mxd). OR (AS ALTERNATIVE TO ABOVE😞 - Enhancement request 2: Don't enable ligatures by default in ArcGIS Pro, as they now are. Instead, leave the option disabled and led the user decide whether or not ligatures should be enabled. Ligatures are likely better off by default given the conflict with the "Spread characters / letters" labeling options of Maplex. If users enable ligatures, and any of the above mentioned settings is enabled, a warning message could be displayed of the conflicting settings. - Enhancement request 3: Clearly document in the Help that the above mentioned settings - Ligatures set to "ON"/selected and label class's "Position/Spread Labels" setting set to "Spread letters up to a fixed limit" or "Spread letters to fill feature" - are incompatible, and especially in combination with text halos. From a user perspective, the technically more complex enhancement request 1 might be preferable over 2, as some languages probably heavily depend on ligatures in the most common fonts used in some countries, so disabling it by default may not be the best option.
... View more
08-29-2018
03:15 AM
|
2
|
0
|
861
|
IDEA
|
You should be more specific as to what you mean. I have successfully used PostgreSQL hstore and json using ArcGIS Query Layers, and am actually pretty much convinced there are few limitations, if any: What is a query layer?—Query layers | ArcGIS Desktop Create a query layer—Query layers | ArcGIS Desktop And for Python scripting using the Make Query Layer tool: Make Query Layer—Data Management toolbox | ArcGIS Desktop Two tips to get this working though: - It may be, or likely is, necessary to use a WITH type query (PostgreSQL: Documentation: 9.6: WITH Queries (Common Table Expressions) to "hide" some of the complexity of using hstore and json functions for ArcGIS. E.g. you cannot include the hstore or json column directly in a Query Layer SQL statement as output column for an ArcGIS attribute table, however, if you use WITH, the lower "nested" queries in the WITH can use hstore and json columns and functions without problems. The resulting CTE will hide this complexity though for ArcGIS, and allow you to access the resulting data columns in ArcGIS. I have had great success with this in ArcGIS, just make sure the outermost SELECT * FROM X type query in the WITH SQL statement does not include the hstore or json(b) columns, so ArcGIS is not confronted with them, as said, only use them in the "inner" SQL statements. - If you are doing automation and geoprocessing using arcpy and Python, using the pyodbc (Home · mkleehammer/pyodbc Wiki · GitHub ) package is a really powerful combination with Query Layers and hstore / json. Using pyodbc, you can create views and materialized views and index & analyze your tables and materialized views to optimize performance. I have done that with great success as well in ArcGIS. Unfortunately, pyodbc is not part of the default install of ArcGIS, but you can use the Python package manager in Pro to easily install them. If using pyodbc, you will also need to install the PostgreSQL ODBC drivers for Windows, you can find them here, make sure you select the proper version for your PostgreSQL installation: PostgreSQL: File Browser
... View more
08-09-2018
02:51 AM
|
0
|
0
|
591
|
IDEA
|
Marco Boeringa, A colleague of mine identified the same problem with the Join condition (adding the tax year) that you did. This query as finally written works when implemented as a database view (on the database side). I did test the SQL query you posted in ArcGIS Pro 2.1 and it still produced the same error message of invalid syntax near WITH. I'm still not sure why it doesn't pass validation in ArcGIS Pro - maybe it doesn't support WITH statements, even though the syntax is valid for SQL Server. I appreciate you sending me in the right direction with the "WITH" statement. That was very helpful and helped me learn something new. I haven't written straight SQL statements for 5-10 years and wasn't aware of some of the new keywords and syntax available. I plan on upgrading to ArcGIS Pro 2.2 in the next few weeks. I'll try it with that version and see if the Make Query Layer works for that.
... View more
07-25-2018
12:11 PM
|
0
|
0
|
357
|
IDEA
|
Marco Boeringa, A colleague of mine identified the same problem with the Join condition (adding the tax year) that you did. This query as finally written works when implemented as a database view (on the database side). I did test the SQL query you posted in ArcGIS Pro 2.1 and it still produced the same error message of invalid syntax near WITH. I'm still not sure why it doesn't pass validation in ArcGIS Pro - maybe it doesn't support WITH statements, even though the syntax is valid for SQL Server. I appreciate you sending me in the right direction with the "WITH" statement. That was very helpful and helped me learn something new. I haven't written straight SQL statements for 5-10 years and wasn't aware of some of the new keywords and syntax available. I plan on upgrading to ArcGIS Pro 2.2 in the next few weeks. I'll try it with that version and see if the Make Query Layer works for that.
... View more
07-25-2018
12:11 PM
|
0
|
0
|
580
|
IDEA
|
Curtis - I think I was on vacation when this came in, and as you know, digging out after UC:) What is being referred to here with "raster analytic tool" are tools from the raster analysis toolbox An overview of the Raster Analysis toolbox—RasterAnalysis Tools | ArcGIS Desktop
... View more
07-17-2018
03:16 PM
|
1
|
0
|
434
|
POST
|
Actually, adding the "Note" text mentioned on the Recalculate Feature Class Extent—Help | ArcGIS Desktop Help page thatJoe Borgione pointed out and that mentions the difference between domains and extents, to the Spatial Reference Help page, would already be a big win.
... View more
06-30-2019
07:03 AM
|
0
|
0
|
400
|
POST
|
Could you post screenshots here of how you view some of this data in ArcMap, ArcGIS Pro and Adobe Acrobat? Just hit the "Print Screen" button on your keyboad and paste in a graphics application if you want to crop the image, or straight in a GeoNet editor window, which also works. One fundamental difference though between ArcMap and Pro, that also may affect how you "view" the PDFs, is that Pro currently maintains all coordinate information of the original data in the PDFs, while ArcMap does a kind of "generalization" to the dpi specified during export. This difference, as I understood it, has to do with some fundamental, Windows level, differences in the display pipeline of ArcMap and Pro. As to some observation by me regarding this, see this post I created in another GeoNet thread: https://community.esri.com/thread/179579#comment-710329 As a consequence, if you have highly detailed data derived at large scales (e.g. 1:5k-1:25k), and view it a small scale (e.g. 1:100k-1:M) without generalizing the data yourself using a tool like "Simplify Line/Polygon", the data may appear very erratic and with "spikes" in a Pro export if the data is also following erratic paths, while ArcMap's output may look smoother and closer to what you would have expected. Especially look closely at the screenshots I posted there to understand what I mean and the differences this may cause in the visible image on your screen.
... View more
06-25-2018
11:04 AM
|
1
|
0
|
1008
|
IDEA
|
Don't know if it is of any use to you, but I recently explored the options to create spatial views using pyodbc and the PostgreSQL ODBC drivers. This seemed to work quite nicely, and I could bring the data back into ArcGIS Pro using Query Layers. You do need to mind data columns you add to the view. Some column types are not supported by ArcGIS. E.g. PostgreSQL's hstore column type for key-value storage cannot be part of the final result of columns in the view (you can use it deeper down in the SQL, just not in the final columns exposed by the view). pyodbc is part of the default Python install of ArcGIS Pro. I only needed to install the PostgreSQL ODBC drivers. pyodbc also supports other databases besides PostgreSQL: Home · mkleehammer/pyodbc Wiki · GitHub
... View more
06-17-2018
03:20 PM
|
0
|
0
|
642
|
POST
|
BUG-000116606 Symbology updates slow after changing the cache settings for layer in ArcGIS Pro.
... View more
10-03-2018
12:12 PM
|
1
|
0
|
763
|
Title | Kudos | Posted |
---|---|---|
1 | 02-05-2024 12:48 PM | |
1 | 12-17-2023 03:40 AM | |
1 | 12-17-2023 03:33 AM | |
2 | 12-14-2023 09:55 AM | |
1 | 04-24-2013 02:02 AM |
Online Status |
Offline
|
Date Last Visited |
yesterday
|