Latest Contributions by VinceAngelo

You could generate a view or SQL query using Query Layers which includes ST_X and ST_Y function calls (the usage for which varies by RDBMS implementation). Since "LONG" is reserved in some databases, I recommend using "LON" to pair with "LAT".   -- PostgreSQL geometry/geography CREATE VIEW mypoints_w_coords AS SELECT objectid,colA,colB,ST_Y(shape) as lat,ST_X(shape) as lon,shape FROM mypoints; -- ORACLE SDE.ST_GEOMETRY CREATE VIEW mypoints_w_coords AS SELECT objectid,colA,colB,SDE.ST_Y(shape) as lat,SDE.ST_X(shape) as lon,shape FROM mypoints; -- SQL Server geometry/geography CREATE VIEW mypoints_w_coords AS SELECT objectid,colA,colB,shape.STY as lat,shape.STX as lon,shape FROM [myschema].mypoints; Note that some elements of geodatabase functionality aren't available with views, so processing the geometry in the client as with Arcade is probably a better solution.   ... View more

No, ArcPy is different between the Python 2.7 and Python 3 releases. ArcGIS Pro (Python 3) is the focus of new development, so it has more functionality than the ArcMap/ArcCatalog/ArcGIS Server (Python 2.7) flavor (besides the new Pro-specific mapping interfaces). The Pro release also bundles the ArcGIS API for Python, which provides easier access to some AGOL/Portal functionality (Enterprise). ... View more

It would help if you provide the Python code you are using, and specify whether the PG database is enterprise geodatabase enabled. - V ... View more

Always make sure you define the correct spatial reference ID in table creation and population, then use that same spatial reference to define the geometry you construct in the query.  The comparison operators all do an initial test of "Do the spatial references match?" and if that fails don't bother to attempt further comparison. You've skirted this problem, then run into the other side of the equation: You've requested a geometry 52.7 meters from the origin of UTM Zone 37N, which is in the Rahole National Reserve in Kenya, instead of a place 242 km northwest of Riyadh, Saudi Arabia. You need to use SDE.ST_Transform()  to convert the lon/lat pair to EPSG 32637, something like: SELECT name1 FROM gtsowner.cm_boundary3_pg WHERE sde.ST_Within( sde.ST_Transform( sde.ST_Point(45.576579,26.460792,4326), 32637), shape)=1; except you need to use the spatial reference IDs (which are defined locally, so I can't know what yours might be), not the coordinate system IDs.  You might need to create a layer with the 4326 coordinate system so that a spatial reference exists (if you haven't already). - V ... View more

ArcGIS 9.3.1 is very ancient. It's unlikely many here remember how the old command-line tools worked, or how to work around geodatabase corruption with the old-style geodatabase architecture. It would help if you provide details on the RDBMS and how you've deployed the software. It sounds as if you have Oracle with the now-deprecated user-schema geodatabases, but exact details are necessary.  Generally, untangling a corrupted geodatabase would be a Tech Support call, but you're nearly a decade late for that. Any advice you receive now would come with a high risk of complete destruction of database integrity, so you might need to provide legal cover to anyone who could help (which would require a time and materials contract with appropriate indemnity). The good news is that the pre-10 geodatabase architecture was more relational, but the bad news is that you're likely working without a net. Sorry. - V ... View more

Unfortunately, that performance is about what I've seen (it's truly awful with 6.1M vertices).  I did some benchmarking, and found I could improve performance by 40-60 percent *and* reduce the size of the resulting string by 20-30%, but only by using 'C' language functions at the lowest level of the component libraries.  The fix would require rewriting the low-level WKT function. - V ... View more

It's actually a 31-character limit (buffer is size 32, including the terminating NUL character). Aliases can go to 64 characters, but the name must still be < 32. Note that the above was from before 10.8, so it depends on the release level of the enterprise geodatabase. - V ... View more

Okay, the People_Tested / People_Hospitalized values are available from the new JHU data files, in the csse_covid_19_daily_reports_us GitHub folder, and exposed in the  ncov_cases2_v1 feature service service, but only at the Admin1 level for the United States (and territories), in layer 3. Given the volatility of the data files in GitHub, I've put together a Python tool to fetch the CSV files, both in realtime and retroactively, renaming previous incarnations if an MD5 hash indicates the file changed.  It doesn't work with Python 3 due to byte/str/unicode issues, so I need to clean that up before publishing... - V ... View more

There's certainly room for an enhancement request along those lines, though I'd do a thorough search for an existing Idea first (Update: And here it is -- I suspect Eric's point about unique names across folders dooms this as an enhancement). I don't have metrics on the performance costs of transactions on Feature Dataset members, but I do know there is more overhead, at least in the initialization and tear-down phases.  The impact is leavened by whether you do one operation or 80 thousand. - V ... View more

The Enterprise geodatabase model (there is no SDE, only Zool) was originally based on the ODBC model, which only supports tables. No RDBMS supports "folders," it's just database.schema.tablename, so any folder organization would have to be implemented in metadata, which may not be standardized across clients (non-geodatabase, JDBC, ODBC,...), and then you have nightmares like dataset corruption because SQL was used to DROP a table and the metadata was not scrubbed (this is the reason that command-line ArcSDE tools were eliminated after 10.2 -- too much data corruption "using Esri tools"). 99.9% of the time that customers complain about locks interfering with schema change operations, it's because they didn't realize that placing 40 feature classes in a feature dataset meant that any use of any of the FCs generates READ locks on all of the FCs in the FDS.  So yes, there's a performance penalty, but more importantly there's a functional complexity penalty.  You can't get simpler than a list of table names out of the system catalog.  The price is paid for a topology because it's worth what you gain, but I find one level of folder organization to be a paltry gain for what it costs. - V ... View more

Heh. So the format change was fleeting, and is now retroactively back to the layout used since 23-Mar, but if it changes again to leverage the new services, I'll be ready.  In fact, I might release the current v3.0 candidate, for those who want access to the new testing and hospitalization data, but I have a data duplication issue to work through first... - V ... View more

Okay, yes, the JHU format changed again tonight, adding five more columns (Incident_Rate, People_Tested, People_Hospitalized, UID, and ISO3). The FIPS column has also moved to a later position. I'll start on recreating the format now... FWIW: The new service is ncov_cases2_v1  and the layer from which to extract Admin2 data is ncov_cases2_v1/FeatureServer/1  - V ... View more

That SQL clause is fraught for failure. An IN comparison on a floating-point value is a recipe for random results -- You could cross-select features with areas that just happen to share a parcel size but don't meet the intended attribute constraint and you might miss intended features due to representation issues. In general, placing the SelectLayerByAttribute inside the cursor iteration is an anti-pattern (because you alter the layer on which the cursor is based), but in this case, it's also unnecessary (because you wanted to restrict the layer before cursor execution would begin). If your dataset supports the full SQL implementation (not file geodatabase or Access), you can use the ROW_NUMBER window function to assign rank in a virtual table, then select parcel identifiers associated with the first-ranked features.  In PostgreSQL the full query could look like: SELECT objectid, continent as continent_name, name as country_name FROM country_gen WHERE objectid in ( SELECT objectid FROM ( SELECT objectid, continent, (row_number() over ( PARTITION BY continent ORDER BY ST_Area(shape::geography) DESC) )::int as group_rank FROM country_gen ) vt WHERE group_rank = 1 ) ORDER BY ST_Area(shape::geography) DESC‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ the output of which is: objectid continent_name country_name 253 'Asia' 'Russian Federation' 29 'Antarctica' 'Antarctica' 18 'North America' 'Canada' 25 'South America' 'Brazil' 223 'Australia' 'Australia' 105 'Africa' 'Congo DRC' 196 'Europe' 'Ukraine' 99 'Oceania' 'New Zealand' You'd only want lines 5-17 in your WHERE clause, suitably altered for your data. ... View more

Okay, so the date format in the 06-Apr JHU file was retroactively changed from "YYYY-MM-DD HH:MM:SS" to "M/D/YY HH:MM" eighteen hours ago.  I'm working on tweaks to the validation parser... - V ... View more