Jump to content

 
Photo

ArcMap 9.3 Annotation FAIL

- - - - -

  • Please log in to reply
6 replies to this topic

#1
Greg Corradini

Greg Corradini

    Contributor

  • Validated Member
  • PipPip
  • 12 posts
  • United States

Is there a way to use annotations as representations? My goal is to override default feature annotation placement with geometric/style edits and still be able to get back to my original placement/style AFTER saving changes. With representations I can bet back to the original styling using a "restore". Is there a way to achieve this with annotations that I don't know about? Has anybody rolled their own to do this? It would be nice. I'm using ArcMap 9.3 sp 1 ArcEditor license.

#2
ceicher

ceicher

    Contributor

  • Validated Member
  • PipPip
  • 44 posts
  • Gender:Male
  • Location:Charlottesville, Virginia
  • United States

Hi Greg,

I had a couple ideas about this.

I. Probably the simplest approach:

-Use feature-linked annotation.

-Edit your annotation as needed.

-When you want to "restore" the original position and appearance of the anno, just delete and re-create.
a) select the anno
B) select the linked source feature (easiest in tree view on left side of the attributes window)
c) delete the anno (still in the attributes window)
d) use "Annotate Selected Features" to recreate the anno.

"Editing feature-linked annotation" > Generating feature-linked annotation from selected features
http://webhelp.esri....nked_annotation

With this, I am not sure that the anno will be exactly back at its original location, but I would give it a try.

II.

Annotation have a rule/override concept similar to (but not the same as) representations. You could exploit this. Getting the original position could again be tricky.

Check out this help topic > heading

"Annotation in the geodatabase" > "Text symbols and symbol collections"
http://webhelp.esri....the_geodatabase

III.

If you make all of your style changes with "text formatting tags", going back to the original is as easy as clearing all the tags.

"Using text formatting tags"
http://webhelp.esri....formatting_tags

Again, not sure about going back to the original position.

My personal opinion is that I is the way to go.

Good luck,

-Cory

#3
Greg Corradini

Greg Corradini

    Contributor

  • Validated Member
  • PipPip
  • 12 posts
  • United States

Thanks for your advice Cory,

I'll try each of these options and track their usefulness. I'll post my findings here.

As far as feature-linked annotation (your first option), I might see a problem with that direction from the start (in terms of usability in my situation). Let's see if I can describe it succinctly.

I'm trying to avoid feature-linked annotation b/c I'm trying to decouple my annotation completely from my data source. The benefit? I describe it as being beneficial to the management of cartographic projects in terms of consistency and historical record.

My data is in an enterprise ArcServer setting and will change often. I don't want my annotation layer being affected by adds/deletes. Its use in any map should continue to be a static historical representation of annotation at the time of map production (my opinion. Open to negotiation). And hopefully it would be stored as such for records keeping. If someone two years from now wanted to remake a map with a layer styled EXACTLY the same way, then it just a matter of loading the annotation. That is one reason (though writing it out makes it seem weaker than I thought).

This leads to my second reason for decoupling. Often my final product annotation for a map is very different from the labeling rules that first created my annotation. Therefore it seems like the benefit of generating new annotation at any given time for a number of features is undermined by all the manual work needed to change each of those annotations to fit the styling of the rest (though I'd have to test this out to be sure) .

Though the biggest benefit of unlinked (decoupled) annotation might be the fact that I can store it at any time (or move it from database to database) without thinking about the data. Of course unlinked annotation makes updates to the annotation layer harder when new data becomes available, but I can see a scripting process to solve this (though I haven't written the script yet).

Anyhoo, writing this out has been helpful (I see some ways to get around my arguments using linked annotation)I'll have to do some serious pros/cons for going either way.

Thanks for the inspiration

#4
Greg Corradini

Greg Corradini

    Contributor

  • Validated Member
  • PipPip
  • 12 posts
  • United States

One more thing. Your name sounded familiar. I've used C#.NET snippets from your posting/ramblings in the past on other sites. I now remember. Your help is appreciated

Greg Corradini

#5
ceicher

ceicher

    Contributor

  • Validated Member
  • PipPip
  • 44 posts
  • Gender:Male
  • Location:Charlottesville, Virginia
  • United States

Hi Greg,

My data is in an enterprise ArcServer setting and will change often. I don't want my annotation layer being affected by adds/deletes.


Technical tip. If you delete the relationship class for a feature linked anno feature class, then this turns off the all updating behavior. Later, you can recreate it (e.g. manually in ArcCatalog) to bring back the behavior. Anno feat class must start out as feature linked... you cannot simply add a rel class to get feature linked behavior (unless you write some code)

Its use in any map should continue to be a static historical representation of annotation at the time of map production (my opinion. Open to negotiation).


I know what you mean, and yes I agree that you typically want to preserve the "state" of the data used to produce map X, version 0.2, on a given date.

Maybe you have a specific situation with your annotation, but what about taking an "archive approach"? You have your live-production database, it is constantly evolving (data are edited), but when you "publish" a map sheet you take care to archive the exact data used in the map sheet.

(detail)There are various ways to do this. The most high-tech and efficient solution (though complicated to setup) would involve ESRI SDE versioning. There are simpler solutions also, e.g. just copying out the "map data" and to some file folder. It just depends how much you want to resuse of this "static" data when you create map X version 0.2, version 0.3 (or if you want to create a map Y which adjoining/overlaps map X and use same data from max X)


This leads to my second reason for decoupling. Often my final product annotation for a map is very different from the labeling rules that first created my annotation.


It depends on how structured you want to be, but a proven approach is to NOT constantly change the schema of your production database. By schema, I mean the names of feature classes, their attribute fields, etc.... but schema for you also includes the annotation properties (e.g. font size, or placement properties for a given anno class). Instead of allowing this to change constantly (e.g. by letting the cartographer change the annotation to be totally different than the source labels), instead you keep a list of all the desired schema changes. Then, when the time comes, you make 5, 10, 50 changes all at once. When you make a set of changes, you "publish" a new version of your schema, giving it a name, version number whatever.

... the important thing is that when you "publish" a MAP (see above), you keep track of the version of the schema used for that map.... this is rather "heavy handed", but with this approach you don't end up having annotation features with completely different styles/properties compared to the source labeling properties (the problem you mentioned). More generally, you have really consistent maps, all based on the same schema (what we would also call a cartographic data model).

Happy to ramble today ;)

-Cory

#6
Greg Corradini

Greg Corradini

    Contributor

  • Validated Member
  • PipPip
  • 12 posts
  • United States

Wow.

Maybe you have a specific situation with your annotation, but what about taking an "archive approach"? ...The most high-tech and efficient solution (though complicated to setup) would involve ESRI SDE versioning...


Yes, this is the way. I most definitely want to be heavy-handed, high-tech, efficient and structured. I have some experience with SDE versioning but not a ton (though I do use GIT a lot for other files. Similar theoretical base I'd think) . Before I read your post I never thought about looking up cartographic data models. Interesting. I need to start looking at those data model diagrams. Where should I do that? I'm sure ESRI. Other places you think I should look?

Though I do now have one versioning issue (if I understood your post correctly):

If I'm creating a ton of maps (assuming that the annotation needs for a given layer are very very different between maps), then I'll be creating a ton of schema version branches off the SDEdefault at map publishing time. Won't I have to reconcile these versions later for fear of running into performance issues? The only way I see this working is if I DON'T ever reconcile those versions with default (preserving historical record). But I'm pretty sure from previous experience that this creates hits in data performance between SDE and DB. I wouldn't want that if the same enterprise data is being consumed by multiple web apps. Maybe I didn't understand your last post right.

Recap (my lingo):
1) Keep "wishlist" of desired changes to annotation
2) If desired changes are critical, then create new annotation version off root (default) with schema naming standard
3) Make changes and save
4) Keep track of schema version at map publishing time
5) Don't ever reconcile (preserves historical record)


Thanks again Cory

#7
ceicher

ceicher

    Contributor

  • Validated Member
  • PipPip
  • 44 posts
  • Gender:Male
  • Location:Charlottesville, Virginia
  • United States

Hi Greg,

All good questions. I can answer only some of them below, but I think you're on the right track in thinking about the design of your system ahead of time.

It could be hard to continue further with this discussion here. What we really need is a whiteboard! I really hope that you find this helpful and you're able to get going based on this and the links.

Best regards,

-Cory

----------------------------------------------------------------------------

-re: versioning schema. You cannot version ArcSDE schema. There is always only 1 schema...

...that being said, the variety you're trying to support (different look for annotation in different maps) probably does NOT require different schemas. I would recommend to read the link above about the annotation symbol collection.

-re: performance degradation in the database caused by many outstanding versions. You are right. If you use a version to preserve the state of your data when a map sheet is produced, and you produce a lot of maps, you could eventually see performance problems. This comes from (as I understand it) a lot of versions + with a lot of edits + open for a long time. note: that you might not actually have this situation (are you making 10,000s of edits per map? probably not).

...you could consider extracting the map sheet data to offline geodatabases (SQL express or .gdb). We do that here. You could also look at Geodatabase Archiving. I don't know much about this.

-re: different maps from a single cartographic data model. my opinion: sde data should be modeled to support making all your different maps...

... I don't know your situation exactly, but your maps must have something in common (otherwise you wouldn't be considering a central data solution). looking only at annotation (text) modeling: if a map has very different annotation, then why not create a new annotation feature class in the central data model? Probably you will create other maps with that same look.

-re: archiving text. following on the previous point (and also picking up the first point too). hopefully you will have a lot of maps using the same annotation feature class. one way to preserve the exact placement (and appearance) of text for a given map sheet is to "tag" all the annotation in a given map sheet version with the map sheet name. then you are free to reconcile and post all your edits back to the parent version, including annotation. sheet specific edits are preserved, and you are also able to close the version.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

-->