|
POST
|
@Thomas_Puthusserry Can you pls do me a favor? pls upgrade to the latest release i.e. 3.6 and try the Spatial Reference picker button from the 2nd page on the New Query Layer dialog; that will bring up the Coordinate System picker; create a new custom projection or import one.
... View more
Tuesday
|
0
|
1
|
54
|
|
POST
|
@Wehara In that case, you really do not need to publish them as feature services. Once map image layers are published, then you can use URLs for individual layers inside a map service to add them as feature layers in a webmap. e.g. if you use this url: https://sampleserver6.arcgisonline.com/arcgis/rest/services/WorldTimeZones/MapServer , a map image layer gets added when you use this url instead (note the layer-id in the end) https://sampleserver6.arcgisonline.com/arcgis/rest/services/WorldTimeZones/MapServer/0, a feature layer gets added to your web map
... View more
|
1
|
0
|
70
|
|
POST
|
@Wehara quick question - do you have any 'editing' requirements from web apps?
... View more
|
0
|
2
|
99
|
|
IDEA
|
2 weeks ago
|
0
|
0
|
134
|
|
IDEA
|
@LindseyStone It should work. Only issue that I am aware was with legend not displaying and we fixed which should be part of 11.5. can you pls reach out to Esri support and open a ticket? we can take a look. In case you have something public, I can take a look at that too.
... View more
3 weeks ago
|
0
|
0
|
259
|
|
IDEA
|
@mthompson there is nothing to apologize for 🙂 'Time in computer' is a confusing topic by itself. Can you publish feature services when editor tracking is in Database Time? I believe it used to throw an error and wouldn't let you. I just gave it a try and I don't see any analyzer error as long as you set the time zone on the Sharing pane during publishing time. for the scenario you mentioned above, if you already have your feature class populated with data, then you should keep your editor tracking fields' time zone in UTC. If it is a brand new and empty feature class, you can choose either UTC or local/database time zone - depending on what works best for you. For you other date/time fields, I'd suggest setting your layer's time zone (if you are in Pro 3.6 and Server 12.0) or service time zone (pre-3.6 or pre-Server 12.0) to EST. You should set the preferred time zone to EST as well. As you might have noticed in the newer releases client apps such as ArcGIS Pro or Map Viewer allows you to switch map's time zone to any time zone. I believe Map Viewer displays date/time values in the machine local time zone. Whereas Pro displays them in preferred time zone when set, otherwise in UTC; but starting at 3.6 you can change the map's time zone to any time zone even when preferred time zone is not set to the service. If I set the service time zone to UTC and the preferred time zone to EST will the regular date/time fields and the editor tracking both display the correct time in EST in the services? that is correct, on the client side date/time values are always displayed in one time zone. If your map is in EST (in pre-3.6, ma, all data from any date/time fields (including editor tracking) will be displayed in EST. Also I'd like to share this recording from an Esri event about 4 years ago. Obviously a lot of things changed/improved since then, but the basic concept remains the same for how date/time values from esriFieldTypeDate travels/stored etc. https://www.youtube.com/watch?v=esb8X-1TtPk
... View more
3 weeks ago
|
0
|
0
|
114
|
|
IDEA
|
@mthompson That recommendation is mostly in the context of editor tracking and when data shared and distributed across multiple time zones. For the case, when data are all in the same time zone, you can use local/database time zone for the editor tracking workflow as noted in the help: Database time is based on the local time zone in which your database resides and should only be used when your data is confined to the same time zone. Aside for the editor tracking workflow, for general usage of date/time values, we don't recommend any particular time zone over other. Whatever works best for your workflow. As long as you work within ArcGIS Pro with your local datasets (with all feature/records/data from the same time zone), you don't need to worry about the time zone. The moment you share your data as a service, we strongly recommend you to specify time zone to your layers before publishing/sharing to enterprise or ArcGIS Online. That being said, in recent releases, we have introduced 3 new field/data types to store date & time. If you pick esriFieldTypeTimestampOffset, then you don't need to worry about time zone; that is because time-zone-offset are stored with data themselves. This allows you storing data from multiple time zones in a single layer/table. They other two types (esriFieldTypeDateOnly and esriFieldTypeTimeOnly) are NOT time zone aware. Values from these two field types are passed around as-is even when they are shared as services and consumed in web clients. I hope you find this helpful.
... View more
3 weeks ago
|
0
|
0
|
129
|
|
POST
|
@HarryPlendl Thanks for sharing the detail error messages, and the solution. It is odd that the upgrade process failed to update the definition of the out-of-the-box print service.
... View more
3 weeks ago
|
0
|
0
|
369
|
|
POST
|
thanks @JohnFannon That is interesting. Print service should take about the same time that Pro takes to do the same task on same setup. At this point, it is better if possible for you, to reach out to Esri Support if the issue continue to persist. Regards
... View more
a month ago
|
0
|
0
|
311
|
|
POST
|
@MattieWiseman I'm not if I should be happy, sad or scared 🤦🏽:male_sign: The code was supposed to save it as an aprx file and not do anything to resolve your issue. Good to know that it is working for you for now. Because you have an issue open with the support, I'd say please let the analyst know about this; and we will look into this. Thank you!
... View more
a month ago
|
0
|
0
|
261
|
|
IDEA
|
hi @DavidOGrady Would you mind reach out to Esri Support and have an issue logged? We need your exact (or sample) data and exact steps to look into this issue. Thank you for reaching out.
... View more
a month ago
|
0
|
0
|
185
|
|
POST
|
@JohnFannon If you haven't already, could try exporting reports (using data from your services, NOT LOCAL datasets) from Pro and see how long it takes? Print service usually takes about the same time as Pro.
... View more
12-10-2025
12:44 PM
|
0
|
2
|
351
|
|
POST
|
@MattieWiseman here is what I'd do: find the line in your py code that calls convertWebMapToArcGISProject() function note the name of the variable that will hold a reference to the result of the function call; Let's say the variable is named result. I think after this line, there are bunch of function calls we have that updates dynamic text element's once all these works are done, get hold of the in-memory ArcGIS Pro project reference and save it as a file by calling result.ArcGISProject.saveACopy(<file-path>). once the task it complete, open the aprx in Pro and take a look at the layers and dynamic text elements on the layout. This usually gives a good clue about what could go wrong. Hope this helps.
... View more
12-09-2025
04:27 PM
|
0
|
2
|
283
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | Tuesday | |
| 1 | 12-04-2025 02:42 PM | |
| 1 | 10-23-2025 03:46 PM | |
| 1 | 08-21-2025 11:11 AM | |
| 1 | 07-30-2025 01:43 PM |
| Online Status |
Offline
|
| Date Last Visited |
Tuesday
|