In ArcGIS online i created a string field with a length of 400 characters...AGOL let me create the field, but when i'm going to do an edition and write a text with more than 254 doesnt work.
Somebody know how to work in ArcGIS Online with string fields with more than 254 characters ??
I appreciate the help that you can give me
Gary Townsend had this issue a year or so ago - Adjusting the Length of a String in an AGOL hosted Feature Service
No one replied with an answer!
Can you load a geodatabase? E.g. Publish features—ArcGIS Online Help | ArcGIS
Text fields in shapefiles have a maximum length of 254 characters so if you save a geodatabase feature class with text fields longer than that to a shapefile, those fields will be truncated down to 254 characters.
The workaround to save your point layer's attribute table as a text file in ArcGIS Desktop using the Export Table command in the table window's menu. This creates a comma separated (CSV file) which you can then import into your ArcGIS Online web map as a layer. Text fields are automatically quoted in the resulting text file, so it is OK if your text descriptions contain commas. Before you do the export, you'll need to add the X Y coordinates of your point locations into the attribute table using the Calculate Geometry command (create two new empty numeric fields then right-click each of them in the table window to get to that command) so ArcGIS Online knows how to georeference the data. The exception is that if your point features already contain street address attributes, you can import the file without adding the XY coordinates, because the ArcGIS Explorer Online client supports geocoding.
The method above only applies to point features, because importing CSV files into ArcGIS Online web maps only supports points. If you have lines or polygons with long descriptions, the workaround is to use shapefiles and break the long descriptions up over multiple text fields.
Actually that's what I've been doing for my point features with long descriptions too. I've added multiple text fields, each of length 254, into my shapefile to contain different sections of the long description. In the popup configuration, you can use the Custom formatting and simply truncate these fields together with a space between each one. See the point features in my map of San Diego for what I mean. Click one of the point features then choose Edit Popup: http://www.arcgis.com/home/item.html?id=1966ef409a344d089b001df85332608f
This gives me a lot of flexibility in how I configure the popup. For example, in the San Diego map I put the first sentence of the description, which I store in one field, at the top of the popup in bold as a quick summary before the address. This method also allows me to easily reconfigure the popup to contain less descriptive text if I want to, without having to edit the source data. Another advantage of splitting long descriptions up into multiple text fields of 254 characters each is that using ArcGIS Desktop 10.1 (to be released next year) if someone opens your web map in ArcMap, the feature classes that ArcMap automatically generates from your web map's point layers will match this field structure. So if an ArcMap user opens your web map, they can get the data from your point layer, use it in geoprocessing or make modifications or additions, save it as a shapefile and then import it into their own web map without any of the descriptive data getting truncated.
Hi Dan, to answer (or give my experience) your question "do you really need that much text?" ..I'm not sure what Deiro's field is storing, but we have run into issues with some of our area descriptions. There is only so much you can abbreviate words to make things fit and still make the description match. We've gone to different methods for this...not all directly GIS storage solutions...but that is why we have a need for text fields much longer than 254. Not trying to start a debate on the merits of text field lengths, but just wanted to point out that there are legit reasons for it.
True...but it has also been my experience that these issues are sometimes not part of the design stage and only appear after-the-fact. In those cases then it needs to be addressed. If not needed, then what is really needed. An example...people trying to include a long description when a hyperlink to a document would be better... or using two columns to split the content would serve in a pinch. But as you say we will debate this later...
First, thank very much to all for respond. I want to give a context of my case.
We have an app published yesterday in the web page of a important colombian radio station (the customer), here the link if you want to check it out: http://www.bluradio.com/horadelasvictimas
Unfortunately i did not consider the issue in mention. The purpose of the app is give to the war victims in colombia the possibility to tell to the public his own history; narrate his experience of kidnapping, forced displacement by armed groups, or many diferent situations.
Each victim can use the aplication and and write the history in the "cuentenos su historia" section, step 2, description's field .... it's the reason of my question.... The real problem ( :D) as you can see, is that the app is "on the air".
Thank you again