Esri’s Parcel fabric offers a clean and efficient way to maintain and edit high quality land records. The fabric joins data into a cohesive structure allowing edits to apply across multiple features in a database. This creates easier workflows, increased data integrity, and reduced headaches for land record managers.

So how do land records transcend the old school’s messy data models into the fluid structure of Esri’s parcel fabric?

1.  Create and set up a staging geodatabase             

• Data clean up with topology rules
• Parcel line preparation

Creation of necessary source data attributes for migration
2.  Create and set up a future geodatabase that will contain the parcel fabric inside Esri’s Local Government Information Model  schema

• Tailor this geodatabase to original land records data (i.e. spatial reference, creation of structure to support migration of source attributes, etc.)

3.  Migrate the data

• This step is computer process intensive and could tie up a machine for a while
• Paramaterization of data migration tool

4.  Review the migration

• It is essential that a thorough review of the newly created parcel fabric is conducted for quality control purposes. There are a few known issues and fixes to employ if a parcel does not migrate into the fabric.

Check out this Esri whitepaper for more information.

For more information regarding the parcel fabric, check out the comprehensive parcel fabric training seminar co-hosted by ROK technologies and Panda Consulting at the college of Charleston March 13-15.

Recently, I did a presentation at SERUG on how you can serve your ArcGIS Server Tiled map services from the Amazon S3 service.  There are several ways to accomplish this....and I have blogged about this before.  But, I think this presentation gives a good overview of how to really do it.  Also included are some code samples for doing this with Flex and Javascript.  The Flex code is way better (because I'm a flex guy), but the javascript code should at least get you started.

If you have never thought about serving your cache this way - you should.  The speed at which you can deliver your cache can be, in most cases, dramatically increased.  I guess if you have a huge fat fiber pipe coming into your organization, you don't have to worry about it, but the vast majority of us could benefit from the huge amounts of bandwidth that S3 can give us.

Check out the presentation here: S3.zip

Ping me with any questions.

Since ROK has become a ArcGIS Server Hosting provider, we are constantly creating cache.  All the time.

I'll hand it to Esri, as they have made the caching process much easier at 10.  I used to have terrible issues with 9.3 crashing on cache creation.  The  new 'Mixed Cache' - which is a blend of png and jpgs - is a welcome addition.  It takes advantage of the jpg small file size and uses png on the edges where it detects transparency.  That was always the downside of of using jps in a big aerial cache - those awful white borders. 

Anyway, so this new Mixed Cache is great and all, but by default, it uses PNG32, which creates monster sized files.  I would have thought that there would be a user config option somewhere, but I have yet to find it.  So, I started to poke around to see how I could do a big giant conversion to changes these PNG32's to PNG8's which have a more reasonable file size.  A quick tweet and and @mapsRus pointed me to their blog that outlined using IrfanView - which makes quick work of batch conversions and modifications to large image collections.  So, just like that, problem solved.  My PNG's are now about one third of the size and look just as good.

So, that brings up the next issue...The 2.x REST based apis all request cached image tiles without the file extension. Previously (1.x apis), they would always include the file extension (.jpg, png, etc) when making these REST requests.  It always puzzled me as to why they would change this, but its quite obvious now.  Your cache can contain multiple image types.  Great, wonderful, but that presented a huge issue for me.  I am a huge fan of storing my cache on the Amazon S3 service - so how will I know what type of file to request? Png or Jpg?  If I upload the cache to S3, and a request comes in for a tile 45678cccc - S3 will deny access because it doesnt exist - 45678cccc.jpg does.  So, before I move my cache to S3, I just need to strip out the file extention.  I used a little util (hundreds of these out there) called RenameMaster.  I was impressed with its speed.  It is wicked fast.  Whew, ok, now I am good to go on S3.

Which leads me to my last little utility....Fast Folder Eraser.  Now I have all these caches that are on my servers taking up space.  What to do?  Ever try to delete a million plus files via windows explorer?  Yeah, its no fun.  To Esri's credit, they have the compact cache now which alleviate the issue of tons of files, but it also doesn't help me when I want to serve my cache from the S3 cloud.  So, make sure to check out that utility.  It can take some time (but still far faster than using windows explorer) to finish, but its impact on the server itself is minimal. 

Happy caching!