Panda Consulting turns 20 years old

Twenty years ago, I formed Panda Consulting with only a vague idea of what we were going to be and stand for as a company. I knew that I wanted to create something that helped others and would be an instrument of service, that we wanted to share with others our knowledge and understanding, and somehow, in our own small way, work towards a better, more informed world.

Having worked for a non-profit for so long, I already understood that in order to make real, meaningful change for the better, whether in organizations or people, you must understand their needs, their aspirations and their challenges. I also knew that we would stand for something important and be guided to enrich the lives of those people we encounter and help. 

Since that day, we have been lucky enough to serve a multitude of people, organizations and causes and we are thankful for each and every one of them. We are constantly working hard to serve each and every one of them and help them find success.

We are driven by the belief that our success is measured not in the number of projects that we help others with, nor the number of employees we might have, but our success is derived by the lasting impact we have upon others, our communities and our environment. 

Panda Consulting is here to stay and, as we move into the future and start to assemble the next generation of leaders in Panda Consulting helping to mentor future leaders, we reaffirm for ourselves and others the following guidelines:

The Panda Way

The real measure of our success is our Client's success.

We will always put the Client's needs above our own.

We will bring understanding to others.

Once you agree to do the work, we do the work.

We will learn from each experience and share those insights with others.

We will create a working environment that helps team members grow to the highest potential.

We will cultivate the culture of learning.

We will understand the project before you start and ensure that the Client has trust in our work.

We can, and will,  always strive to do better.

Thank you to everyone who has trusted in Panda Consulting over the years for allowing us to help you in your work and we look forward to continuing to help you and others well into the future.

 

Curves in the Parcel Fabric

There are many ways in which the Parcel Fabric differs from our current mapping concept, some of them are obvious, such as the tools we use and the way we store land records data. But there are also subtle differences that we need to understand to make the most of the Parcel Fabric - We need to especially recognize that the Parcel Fabric stores curves differently.

Screen Shot 2014-01-15 at 11.22.18 AM.jpg

Feature Class Curves

Within a standard feature class, the curve is a variation on a single line vector. Albeit, the curved line has specific properties that define the amount that the curve is "bent". In fact, when we interact with the curve using the standard editing tools, we are actually just changing those specific properties that define the curvature.  

Because of the way the curve (arc) is stored, there are many tools in ArcGIS to help you define those specific properties to cause a curve to pass through start, middle and end points (arc function) or through specific endpoints (endpoint arc function), tangent to a previous course (tangent arc) or even a bezier curve (bezier). 

A Curve as defined in the Parcel Fabric

A Curve as defined in the Parcel Fabric

 

Parcel Fabric Curves

However, within the Parcel Fabric, curves are constructed and stored as geometric definitions and the actual point of curvature (PC), point of termination (PT), the radius point (RP) and radius lines are constructed and stored. These points and lines define how the curve is drawn. Interestingly, because the actual arc of the curve is constructed within the Parcel Fabric, you cannot join or link to the actual curve - you must join or link to the defined points (Point of Curvature, Point of Termination or Radius Point.)

Screen Shot 2014-01-15 at 12.20.44 PM.jpg

The implications of this difference in the way curves are stored are important to understand. For example, if two curves are stored in the Parcel Fabric and are supposed to be concentric and there are any variations in the location or geometry stored with those curves, they will create differing points and will not be drawn as concentric. Instead, there will be two different points stored as illustrated to the right. In this example, the two curves were stored and there was a difference in the radius length stored ( this was not necessarily an error, this difference could have been simply a rounding error on the original information.) But, having these two points stored as different values will result in the curves not being drawn concentrically. 

To remedy this issue, you must force those two points to be stored as one.  To accomplish this, you use the Mean Points tool in the Parcel Editor Toolbar. 

The Mean Points tool in the Parcel Editor Toolbar

The Mean Points tool in the Parcel Editor Toolbar

Dragging a box around the points to be "meaned" (averaged) will move the points together and result in having the curves drawn as concentric, even if they have differing COGO information stored in their respective geometries.

Remember, within the Parcel Fabric, the actual joins to points and linepoints is critical to how your data is drawn.  Be sure to check to make sure the points are joined correctly and that all three points in the curve (PC, PT and RP) are correct.

Is the Parcel Fabric worth the squeeze?

summer_lemonade.jpg

"Is the Juice worth the squeeze?" is one of my favorite expressions - it so clearly focuses the decisions we make, especially relating to technology. I am reminded of this today as I was discussing with two of our clients whether to remap their parcels in the Parcel Fabric for parcel maintenance purposes.

By far, the greatest challenge with the Parcel Fabric is transitioning from your current data model into the highly structured Local Government Information Model. 

You may currently be using a "cartographic" data model in which you use lines and pieces of text to convey information about the features contained on your map. While this model is great if your primary focus is in producing that map, it does not provide a complete picture as far as this elements on which you wish to store information.  For example, you may only store lines showing where the extent of lots differ from the extent of tax parcels, or you may store pieces of text to convey dimensions instead of actually storing the information as an attribute of the lines.  While not trivial, these deficiencies can be overcome for the transition into the Parcel Fabric.

Or, you may have issues with topology.  Storing features in separate feature classes, or "layers" often leads to having features that do not "line up" with features in other layers. While not difficult to correct, especially with the many topology tools in ArcGIS, the process is often time consuming and tedious.  Be warned, this MUST be corrected prior to transition into the Parcel Fabric. While there are procedures for correcting these issues in the  Parcel Fabric, it is far easier to only import features that align with each other.

Finally, you may find you have issues with the spatial location of your features. While there are many ways to correct the spatial location in the Parcel Fabric, including moving the features, and least squares adjustments, since features in the Parcel Fabric are interconnected, when you move one feature, it will change any connected feature.

I am a licensed Surveyor in several states who has been involved in GIS for over three decades and, without a doubt, the Parcel Fabric is the best data model we have seen for the storage and maintenance of land records. The Parcel Fabric is the first data model that allows us to keep and maintain essential information about a particular parcel within the model.  What is the document that created, modified or defined this parcel? Is there a digital copy of that document available for viewing? What are the dimensions of the boundary as shown on the originating document? What are the mapped dimensions? What rotation or scaling had to be performed to make the parcel fit? Are there differing boundary dimensions for the adjoining parcels? What are the lines associated with a specific parcel? These are just a few of the questions that the Parcel Fabric allows us to answer.

We plan on discussing in an upcoming post the advantages of the Parcel Fabric, but, for now, understand that, while the data model is a great incentive for transitioning, the maintenance of your land records is the main reason to consider moving into the Parcel Fabric.

While not perfect, the tools that ESRI has built for the Parcel Editor continue to get better and better with each new release. I am amazed by the fact that a single tool can perform in one step as many as five separate steps required when editing features that are stored with corresponding topology rules. Granted, you must take the time to learn and understand these new tools to truly become efficient with the procedures, but, as with all things in life, this efficiency comes with time and experience.

We provide parcel maintenance services for many counties and, after transitioning all of these counties into the Parcel Fabric, we find that the time we spend on the actual maintenance of the data is greatly reduced, more controlled and reproducible, and we are better able to document and track the results of this maintenance. As a matter of fact, we have seen reductions of the time it takes to perform this maintenance of up to 50%.  That, my friends, is the main reason to consider, and transition your parcel data into the Parcel Fabric.

The Parcel Fabric is worth the squeeze.