Timeline for How to Transform Many Projections Into One With SQL Server
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 16, 2017 at 3:17 | history | edited | PolyGeo♦ | CC BY-SA 3.0 |
deleted 30 characters in body; edited tags
|
| Apr 27, 2016 at 0:36 | vote | accept | TSJ | ||
| Apr 20, 2016 at 13:05 | answer | added | Jürgen Zornig | timeline score: 3 | |
| Mar 6, 2015 at 21:04 | history | edited | TSJ | CC BY-SA 3.0 |
More clarification of the situation
|
| Mar 6, 2015 at 20:55 | comment | added | TSJ | I'll update the answer with the code I'm using right now. | |
| Mar 6, 2015 at 20:52 | comment | added | Vince | Are you using a dictionary to store the source coordinate references? What version of ArcGIS are you using? Are you using DA cursors? I doubt you'd see a performance difference between the most efficient implementations with FGDB and EGDB targets. | |
| Mar 6, 2015 at 19:05 | comment | added | TSJ | You are right. There are about 40,000 points for now, but I expect it to get up to a few hundred thousand. I'm using arcpy.PointGeometry.projectAs for each point as I'm going through the table. It was a simple implementation until we figured out a better way to structure the database in the backend. I am assuming that having a database table ready to go in the right projection will still be faster than finding another way to implement the transformation on the user's side. Is this true? | |
| Mar 6, 2015 at 18:25 | history | edited | Vince | CC BY-SA 3.0 |
removed thanks as per policy; fixed typo ("hot" -> "how")
|
| Mar 6, 2015 at 18:24 | comment | added | Vince | How many million point features in this table? Maybe you should look at the efficiency of the Python code. | |
| Mar 6, 2015 at 18:16 | history | asked | TSJ | CC BY-SA 3.0 |