|
POST
|
Thomas, Did you ever get a step further with this? Also considering the UC is long past.
... View more
10-03-2018
09:04 AM
|
0
|
0
|
7454
|
|
IDEA
|
I think it would be really helpful if you specified exactly what software, and version of that software, you are referering to. ESRI has dozens of software solutions on offer. Just saying you miss some functionality is not going to get us anywhere.
... View more
09-12-2018
07:28 AM
|
0
|
1
|
920
|
|
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
|
1
|
1778
|
|
POST
|
I have now finally found the time to create an ArcGIS Idea with some of my ideas about what needs to change to the Query Layer framework to make it really usable against (ultra) large databases: https://community.esri.com/ideas/15422 Vote it up!
... View more
08-16-2018
04:07 AM
|
0
|
1
|
2004
|
|
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
|
1577
|
|
POST
|
Hi Thomas, Please note this is just my opinion, I don't work for ESRI, I am just a user like you: This is one point where I unfortunately do not agree with your "simple" conclusion. The problem is, there are simply two types of ArcGIS users and organizational workflows: some WANT relative paths always, others DON'T (like the OP here), and both groups tend to have strong opinions about this. ESRI actually probably decided to change the default based on numerous requests on the Forums and ArcGIS Ideas. E.g., see this strong plea for having relative paths as default instead of absolute ones: For the love of god, make "Relative Paths for data source" the installation default. For the love of god, make "Relative Paths for d... | GeoNet I think the title speaks for itself... just like there are many adepts for absolute paths here in this thread, there are many organizations who have setups that actually benefit from having relative paths by default, even if this seems alien to the opposite group. That said, given this situation, the only logical conclusion for ESRI should be to support both workflows... Keeping the "relative paths default", that means indeed implementing an "absolute path" option, so that users can switch the behavior of ArcGIS Pro at will and adjust for their organization's workflows. Switching the default back to absolute paths would be senseless given the described situation.
... View more
08-07-2018
06:58 AM
|
2
|
0
|
4888
|
|
POST
|
One thing i do not fully understand is that in a situation where you regularily move projects and data, you probably want relative paths. It doesn't make much sense to move a project to a totally different folder structure in terms of finding it back. Nonetheless, if you do desire to always have absolute paths, then reffering back to my previous post, your best bet for now is to reserve a totally separate drive to store all of your project documents, and to never save data there. This way you will force Pro to always use absolute paths. E.g. always store all projects on E: and data on F: drive.
... View more
08-02-2018
11:04 AM
|
1
|
1
|
5762
|
|
IDEA
|
Andrew, I now noticed it actually seems the counts you are calculating are wrong, because the joins don't take into account the tax year. If I now properly understand it, I think your query needs to look like this to get the proper residential and commercial counts for each tax year, so try inserting this as the Query Layer SQL statement: WITH ComboQuery As ( SELECT R.GeocodeSearch,R.PropertyID,R.TaxYear,R.ResCount,C.ComCount FROM ( (SELECT Property.GeocodeSearch,Property.PropertyID,Property.TaxYear, COUNT(Res.PropertyID) AS ResCount FROM Property JOIN Res ON Property.PropertyID = Res.PropertyID AND Property.TaxYear = Res.TaxYear GROUP BY Property.GeocodeSearch,Property.PropertyID,Property.TaxYear) AS R JOIN (SELECT Property.GeocodeSearch,Property.PropertyID,Property.TaxYear, COUNT(Com.PropertyID) AS ComCount FROM Property JOIN Com ON Property.PropertyID = Com.PropertyID AND Property.TaxYear = Com.TaxYear GROUP BY Property.GeocodeSearch,Property.PropertyID,Property.TaxYear) AS C ON R.PropertyID = C.PropertyID AND R.TaxYear = C.TaxYear ) ) SELECT * FROM ComboQuery WHERE TaxYear = 2017;
... View more
07-25-2018
06:22 AM
|
0
|
1
|
1236
|
|
IDEA
|
Andrew, I now noticed it actually seems the counts you are calculating are wrong, because the joins don't take into account the tax year. If I now properly understand it, I think your query needs to look like this to get the proper residential and commercial counts for each tax year, so try inserting this as the Query Layer SQL statement: WITH ComboQuery As ( SELECT R.GeocodeSearch,R.PropertyID,R.TaxYear,R.ResCount,C.ComCount FROM ( (SELECT Property.GeocodeSearch,Property.PropertyID,Property.TaxYear, COUNT(Res.PropertyID) AS ResCount FROM Property JOIN Res ON Property.PropertyID = Res.PropertyID AND Property.TaxYear = Res.TaxYear GROUP BY Property.GeocodeSearch,Property.PropertyID,Property.TaxYear) AS R JOIN (SELECT Property.GeocodeSearch,Property.PropertyID,Property.TaxYear, COUNT(Com.PropertyID) AS ComCount FROM Property JOIN Com ON Property.PropertyID = Com.PropertyID AND Property.TaxYear = Com.TaxYear GROUP BY Property.GeocodeSearch,Property.PropertyID,Property.TaxYear) AS C ON R.PropertyID = C.PropertyID AND R.TaxYear = C.TaxYear ) ) SELECT * FROM ComboQuery WHERE TaxYear = 2017;
... View more
07-25-2018
06:22 AM
|
0
|
1
|
1518
|
|
IDEA
|
Andrew, Can you attempt the following much simplified query as the SQL statement for the Query Layer? It is based on your original first post here. This query passes validation in SQL Fiddle, but is structured fundamentally different as you can see: WITH ComboQuery As ( SELECT Property.GeocodeSearch,Property.PropertyID,Property.TaxYear, COUNT(Res.PropertyID) AS ResCount, COUNT(Com.PropertyID) AS ComCount FROM Property LEFT JOIN Res ON Property.PropertyID = Res.PropertyID LEFT JOIN Com ON Property.PropertyID = Com.PropertyID GROUP BY Property.GeocodeSearch,Property.PropertyID,Property.TaxYear ) SELECT * FROM ComboQuery WHERE TaxYear = 2017;
... View more
07-24-2018
03:19 PM
|
0
|
0
|
1236
|
|
IDEA
|
Andrew, Can you attempt the following much simplified query as the SQL statement for the Query Layer? It is based on your original first post here. This query passes validation in SQL Fiddle, but is structured fundamentally different as you can see: WITH ComboQuery As ( SELECT Property.GeocodeSearch,Property.PropertyID,Property.TaxYear, COUNT(Res.PropertyID) AS ResCount, COUNT(Com.PropertyID) AS ComCount FROM Property LEFT JOIN Res ON Property.PropertyID = Res.PropertyID LEFT JOIN Com ON Property.PropertyID = Com.PropertyID GROUP BY Property.GeocodeSearch,Property.PropertyID,Property.TaxYear ) SELECT * FROM ComboQuery WHERE TaxYear = 2017;
... View more
07-24-2018
03:19 PM
|
0
|
0
|
1518
|
|
IDEA
|
Andrew, Sorry, I did not look at the SQL Fiddle link you posted. I now see that the syntax and SQL statement you posted, actually does pass the validation in SQL Fiddle, so is probably correct, and my first suggestion of an alternative or fix in the post above incorrect. I have hence removed the suggestion.
... View more
07-24-2018
02:18 PM
|
0
|
0
|
4369
|
|
IDEA
|
Andrew, Sorry, I did not look at the SQL Fiddle link you posted. I now see that the syntax and SQL statement you posted, actually does pass the validation in SQL Fiddle, so is probably correct, and my first suggestion of an alternative or fix in the post above incorrect. I have hence removed the suggestion.
... View more
07-24-2018
02:18 PM
|
0
|
0
|
5981
|
|
IDEA
|
Hi Andrew, Yes, WITH can seem a bit confusing at first, but is actually quite simple. Unfortunately, many of the examples given on the internet start out with example SQL statements that are way to complex for anyone trying to understand it properly. In essence, WITH boils down to: WITH <YOUR_TABLE_ALIAS_NAME> AS ( <PUT THE ORIGINAL - UNMODIFIED! - QUERY HERE THAT GIVES YOU ISSUES> ) SELECT * FROM <YOUR_TABLE_ALIAS_NAME> WHERE <A POTENTIAL WHERE CLAUSE> So you simply need to put the original query within the brackets of the name alias definition of the WITH, and use the alias name a second time in a SELECT * FROM...WHERE after the closing bracket. So the alias should appear twice. I only see it once in your query (ResQuery) and I miss the closing bracket for the alias definition. So I guess you want to have something more like this, notice the last line with closing bracket and second reference to the alias name. Please note I have never used a construct like you do here with queries concatened with comma's, so don't know entirely sure if this is the right syntax to make it work.: NOTE: SQL removed as the answer was incorrect!
... View more
07-24-2018
01:08 PM
|
0
|
1
|
4369
|
|
IDEA
|
Hi Andrew, Yes, WITH can seem a bit confusing at first, but is actually quite simple. Unfortunately, many of the examples given on the internet start out with example SQL statements that are way to complex for anyone trying to understand it properly. In essence, WITH boils down to: WITH <YOUR_TABLE_ALIAS_NAME> AS ( <PUT THE ORIGINAL - UNMODIFIED! - QUERY HERE THAT GIVES YOU ISSUES> ) SELECT * FROM <YOUR_TABLE_ALIAS_NAME> WHERE <A POTENTIAL WHERE CLAUSE> So you simply need to put the original query within the brackets of the name alias definition of the WITH, and use the alias name a second time in a SELECT * FROM...WHERE after the closing bracket. So the alias should appear twice. I only see it once in your query (ResQuery) and I miss the closing bracket for the alias definition. So I guess you want to have something more like this, notice the last line with closing bracket and second reference to the alias name. Please note I have never used a construct like you do here with queries concatened with comma's, so don't know entirely sure if this is the right syntax to make it work.: NOTE: SQL removed as the answer was incorrect!
... View more
07-24-2018
01:08 PM
|
0
|
1
|
5981
|
| 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 |
2m ago
|