POST
|
Thanks Andrew. ArcGIS Open Data is looking very promising so far!
... View more
05-09-2014
02:24 AM
|
0
|
0
|
185
|
POST
|
Hi, I haven't tested this, but if JSONP and CORS aren't supported by ArcGIS Open Data, then you will need to use a server-side proxy page: https://github.com/Esri/resource-proxy https://developers.arcgis.com/javascript/jshelp/ags_proxy.html Simon
... View more
05-09-2014
02:22 AM
|
0
|
0
|
222
|
POST
|
Hi, I was wondering if anyone else feels a need for these? The "quick wins" (ones I think could be implemented fairly easily, although I could be completely wrong about the effort involved!) are listed first. 1) This is more of a request for clarification than new functionality: it appears that data can be exported from an Open Data portal even if the item owner has disabled "Allow others to export to different formats" in the item properties. The "Extract Data" tool in ArcGIS Online respects this setting, but the Open Data portal does not. I can see the advantage of doing this, as the default setting (I think?) is to not allow exports, and having an opt-out rather than opt-in policy makes setting up a portal easier. Could this override be clarified in the documentation (assuming it isn't already?) 2) Have an option to preserve the original coordinate system of data when exporting to shapefile (at the moment, data not in WGS-84 lat/longs is converted to WGS-84). I work with British National Grid data a lot and there is some loss of accuracy when the coordinate system is changed, although it does appear that conversion is done using the accurate (to about two metres) Petroleum transformation, so this isn't a huge deal for me. 3) When exporting point feature layers to CSV, would it be possible to add the lat and long of the point geometry into two extra fields. This would be useful for Esri Maps for Office users. 4) Allow map notes and other layers embedded in a webmap (e.g. GPX, CSV, shapefiles, etc) to be exported. 5) Enable HTTPS access to Open Data portals. 6) Add support for exporting hosted tile services.
... View more
05-02-2014
03:05 PM
|
0
|
0
|
1845
|
POST
|
If you search an Open Data portal, and your results include a hosted tile service, the UI freezes and you're forced to reload the page. To see this, you can search for "China" on the following portal: Test Portal The search result (delivered in JSON format) seems to be coming back from the server correctly, but there are null values in the response that the JavaScript code doesn't seem to like. Could this be fixed? Ideally, tiled services should be supported in the same way that feature services currently are, or they should be excluded completely when users are searching an Open Data portal.
... View more
05-02-2014
02:37 PM
|
0
|
2
|
1430
|
POST
|
In this example, the DateTime field is exported as a signed 32-bit integer (and the values look quite random) rather than any kind of date I can understand: Example The original feature service can be viewed in ArcGIS Online as a time-enabled layer: Webmap
... View more
05-02-2014
02:17 PM
|
0
|
0
|
1842
|
POST
|
I'd like to second this. For example, the service below has Chinese characters in the attribute fields: http://simon.techresearch.opendata.arcgis.com/datasets/9f0d2f8db081426eb396837a1bc77f68_1 Downloading as CSV is fine. Downloading as a shapefile corrupts the text. However, from memory, the DBF format used by shapefiles to store attribute data has always had spotty support for non-ASCII characters, so there may not be much that can be done here. Downloading as GeoJSON and viewing in a text editor seems to work OK, but I've noticed that when I click http://simon.techresearch.opendata.arcgis.com/datasets/9f0d2f8db081426eb396837a1bc77f68_1.geojson in my web browser, the Chinese characters are garbled if my browser's default encoding isn't set to UTF-8 (this will be the case for a lot of users in English-speaking countries). This can easily be fixed by getting the server to state the encoding in the HTTP response header (something like Content-Type: text/plain; charset=utf-8 rather than the ambiguous Content-Type: text/plain it sends at the moment)
... View more
05-02-2014
01:31 PM
|
0
|
0
|
271
|
POST
|
I've encountered a related issue: adding an item to an Open Data group also doesn't trigger the Open Data portal's index to refresh. I waited 15 minutes and nothing happened. One work-around I've found is to temporarily create a second Open Data portal from the group, which seems to force the index in both portals to refresh. You can then delete the second portal. Obviously, having to do this every time you want to add new items isn't ideal!
... View more
05-02-2014
01:00 PM
|
0
|
0
|
510
|
POST
|
Hi, Can you check your firewall settings on the Dashboard machine (not the XMPP server)? As a test, you could disable the firewall and see if that works. Simon
... View more
01-27-2014
04:01 AM
|
0
|
0
|
246
|
POST
|
Hi, There weren't any errors in the Analyze stage, and I'm using a full subscription account. I've reported the issue to Esri Technical Support as suggested. Meanwhile, this was the dataset I tried to publish (it uploaded successfully): http://www.arcgis.com/home/item.html?id=423593dd68b441e38d31d58fc31ff98e
... View more
12-17-2013
07:47 AM
|
0
|
0
|
291
|
POST
|
Hi, I tried publishing a 30-million-point feature class (585 MB) to AGOL yesterday. I was using Desktop 10.2 and the feature class only had a couple of text attributes. After spinning for five hours, I got an unknown error message (probably related to the size of the dataset!) and the publishing process failed. Has anyone tried something similar and are there any known limits to the capacity of hosted feature services? In the past, I have seen an AGOL hosted feature service with half a million polygons, which must have had several million vertices, but it's quite possible that the feature count is more important than the number of vertices in deciding whether the publishing process succeeds or not. Many thanks, Simon
... View more
12-13-2013
12:21 AM
|
0
|
3
|
861
|
POST
|
Hi Jason, The most important thing is to set geodesic to true. This will create an accurate buffer from projected units and the bufferSR parameter will be ignored. If you have Web Mercator input geometries, the inSR and outSR should both be set to 102100. In addition, make sure that you specify the buffer unit correctly. The US survey foot has a WKID of 9003 and the international foot is 9002. http://resources.arcgis.com/en/help/arcobjects-cpp/componenthelp/000w/000w00000042000000.htm
... View more
12-10-2013
01:09 AM
|
0
|
0
|
247
|
POST
|
This could be completely wrong, but I have a hunch that you're dividing by 0 somewhere and that's causing Python to fall over. When you calculate percentage complete, you divide by a number obtained from the "Get Count" tool. If there is a count of 0, this division should be avoided using a simple if-statement check.
... View more
12-10-2013
12:35 AM
|
0
|
0
|
185
|
POST
|
CSV files must specify point locations using WGS 1984 lat/longs. They are then projected into whatever coordinate system the basemap uses (Web Mercator for the ones in the standard basemap gallery). At the moment, points from a CSV layer do not have any datum transformation applied to them when they are being projected, so if the basemap uses a projected coordinate system not based on WGS 1984 (e.g. British National Grid), then the points could be several hundred metres out. Map notes captured in the ArcGIS.com web viewer use the coordinate system of the basemap. The measure widget in the ArcGIS.com web viewer uses geodesic area calculations on a server-side geometry service, so the calculation should be accurate. More details here: http://resources.arcgis.com/en/help/rest/apiref/areasandlengths.html (see "calculationType" on that page)
... View more
12-06-2013
02:57 AM
|
0
|
0
|
292
|
POST
|
Hi, It sounds like you are projecting your input layers only for display, but the underlying data is still in WGS 1984. You need to run the Project tool (Data Management -> Projections and Transformations -> Feature -> Project) on each of your data layers, setting the Output Coordinate System to 102443 (which is TWD_1997_TM_Taiwan). Then, you can run Generate Near Table on the resulting layers. The units used should be metres. Regards, Simon
... View more
12-04-2013
05:54 AM
|
0
|
0
|
146
|
POST
|
A quick update: I installed ejabberd on another machine and everything (including group chat) seems to work now. I'm not sure what's changed, but I don't have time to investigate this further. I'm still having problems with group chat using Openfire (version 3.8.1 for Windows) on this new machine. For reference, my successful setup is running ejabberd 2.1.11 on Windows 7 (64-bit), downloaded from the link in the previous post. The firewall is disabled on the server. In the absence of other information, it seems ejabberd is a viable choice for a chat server with Dashboard. YMMV, of course.
... View more
03-05-2013
02:06 AM
|
0
|
0
|
160
|
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|