|
POST
|
What spatial type is your fabric stored in? If it is GEOMETRY, copy and paste the fabric as SDEBINARY and test the behavior again, and vice-versa if it is already stored as SDEBINARY (Esri Binary). You can find out the spatial type from the General tab on the properties of one of the fabric classes. [ATTACH=CONFIG]28730[/ATTACH] During copy and paste, you will be prompted to choose the spatial type. [ATTACH=CONFIG]28731[/ATTACH] Thanks, -Tim
... View more
10-30-2013
01:18 PM
|
0
|
0
|
521
|
|
POST
|
Hi Greg, In the context of loading a topology to a fabric, the Exceptions are reserved for lines that are to be imported as non-boundary lines, or non-road frontage lines, or for lines that do not form a required boundary of a parcel and should be ignored. For example: by definition, a connection line will break the rule "Must be Covered by Boundary of" However, this should not prevent you from importing connection lines, and so you can mark these lines as exceptions, place a field on the source data called "Category" and then populate these lines with the value '3' so that they will then be imported as connection lines. If they are to be ignored then you'd mark them as exceptions and not give them a category value at all. There are some limits to what should be marked as an exception. For example, if an exception is set on a line that would be used as a boundary if it were not for its topology error, then the results of the import may result in the type of problems that you are reporting. -Tim
... View more
10-07-2013
06:16 PM
|
1
|
0
|
676
|
|
POST
|
Hi Dan, Thanks for sharing the file. I've taken a look; I understand what's happening, and I have a resolution for you. Since the original file format has no built-in notion of the different line categories, when the data is first loaded the parcel editor grid is not able to identify (or assume) which lines form a closed loop, and so it is flagging the parcel as unclosed. You've already noticed that the lines all automatically come in as boundary lines. You've correctly set your first two lines as category 6- Origin Connection lines. The only other thing that you need to do is set the parcel's "unclosed" attribute to false. It's possible that this field may not be turned on for the target parcel layer, so you'll need to turn that field on first, as shown in the graphic: [ATTACH=CONFIG]28108[/ATTACH] -Tim
... View more
10-07-2013
04:44 PM
|
0
|
0
|
1277
|
|
POST
|
Mike, This is not something that I've heard reported before. I�??ve tried a few things that might explain what you�??re seeing, but nothing I�??ve done so far gives me the same results that you see. Note, that in terms of the fabric data, the parcel editing environment will always use the control point attributes over its geometry, but the control point geometry and fabric point geometry should still match their respective attributed coordinate locations. Another possible scenario that would only partially explain what you're seeing is that your original import source data itself has this same 5ft discrepancy between its geometry and it's X/Y coordinate. In this scenario the control importer honors the source XY attributes and would not match the original geometry position of the source data, unless you checked the option on the control importer to use the shape field. [ATTACH=CONFIG]28104[/ATTACH] For your data, what happens if you make a temporary small edit (0.01ft change to one of the coordinates) to the control point, (using the Maintain Control Points dialog) save the edit, and then re-edit the control point back to its original value? Do those edits move the control point to the entered attribute position? If none of this addresses or explains your case, please contact tech support to help us better understand what you are seeing. If there are any other readers of this forum that have experienced similar, please respond on this thread and also contact tech support referencing this post so that we can identify patterns and symptoms. Thanks, -Tim
... View more
10-07-2013
03:42 PM
|
0
|
0
|
1105
|
|
POST
|
Hi Mike, What is the distance between the coordinate position and the geometry's position? Is the distance close to the XY tolerance for stored geometry as described in this help topic called The properties of a spatial reference ? If this distance is small, and you are zoomed way in, then the XY tolerance may explain what you are seeing. Also, is the parcel fabric in a geographic coordinate system, and you're projecting on the fly using the map's data frame; or is the fabric's spatial reference a projected coordinate system, and the same as the map's projected coordinate system? Thanks, -Tim
... View more
10-03-2013
04:12 PM
|
0
|
0
|
1105
|
|
POST
|
Hi Daniel, Would you please copy/paste the text of the traverse file (or attach the file) so that I can try it? Not sure of the geometry properties of the data represented in the file, but loading traverse files of this format is most suited to files that each represent individual closed parcels. As you are probably aware, this file format doesn't specifically support connection lines. Though you can change the category of the lines after you've done the import, in a workflow where you are importing closed loop traverses, I'd expect ALL the lines to be either boundary lines or road frontage lines. Connection lines are more like "side-shots" to use the term from the older Workstation ArcCOGO technology. So connection lines should not be used to represent a parcel perimeter. There is more information about parcel line categories, and parcel "anatomy" in this meetup recording, starting at around about 48:30. Thanks, -Tim (Parcel Editor team)
... View more
10-03-2013
01:40 PM
|
0
|
0
|
1277
|
|
POST
|
Starting with ArcGIS 10.1, there's a tool, called Merge Courses, that will generate line-points for you after you've imported the fabric, so you don't need to worry about figuring out the line-points on the original source data, prior to the import. To use this tool you select imported parcels that you'd like to create line-points for, using the parcel selection tool, right-click to access its context menu, and click Merge Courses. More information about this functionality is available in the help topic '>Data review and cleanup tools. -Tim
... View more
08-23-2013
03:07 PM
|
0
|
0
|
1037
|
|
POST
|
Please note that the occurrence of empty geometries in the fabric is by design. These represent parcels that have not yet been joined and integrated into the rest of the fabric. These are stored in an �??unjoined�?� state, waiting to be joined (connected) with the other parcels in the fabric. They are stored in the fabric tables with empty geometries. There is more information about unjoined parcels and empty versus null geometries in this forum post. I've attempted to reproduce the case that you are experiencing with the large extents, but without success so far. If you haven�??t done so already, please contact tech support so that it can be properly tracked and recorded. Is there a particular worklfow that you can identify as causing the problem? Another question: you�??ve noted in your post that the General tab states �??Storage: High Precision using Geometry spatial type (SRID 0)�?� To confirm what you're seeing on that General property page: it does not state �??�?�using ST_Geometry spatial type�?��?� ? In other words this particular reported property has two problems; first is that the SRID is reported as 0, and the second is that it is not reporting the �??ST geometry�?�? Thanks, -Tim (Parcel Editor team)
... View more
08-20-2013
03:50 PM
|
0
|
0
|
2219
|
|
POST
|
I've attached an image for the entry of the second case, using the same Plan settings as for the first case. Chris' suggestion is for instances where you do not have enough information for a circular arc's orientation. For example, in the second case, if there were no radial bearings to define the orientation of the curve, you would start at the south east corner, cogo in the first three straight lines, digitize in the last closing course as a straight line, and then edit the last course by entering in the radius. The downside of this is that you are not getting the benefit of closure, and ensuring that no mistakes were made in the entry of the prior courses. In some scenarios you may have no choice but if there is enough information, as shown in this data, then it's better to enter the complete curve information, and get the benefit of the QA from the misclose information: [ATTACH=CONFIG]23726[/ATTACH] -Tim
... View more
04-23-2013
08:49 AM
|
0
|
0
|
831
|
|
POST
|
Within the US the only place I'm aware of that have plans that use South Azimuth is Hawaii. You would never see both North Azimuth and South Azimuth on the same plan, and so you'd definitely not be switching between the two while entering information on the same plan. However, there are also differing conventions on placement of the bearing in relation to the line, with respect to which way the line is running. For example, you'd ask yourself the question "Is the bearing annotated on this line oriented from point A to point B or is it going from point B to point A?" If you are at point B, and you want to get to point A, but the bearing shown on the plan is going the other way, then you need to add or subtract 180 degrees from the bearing to enter the value to run the line the correct way. I see what you're referring to about the comparison between the first and second curves. There is an apparent inconsistency in the way the radial bearings are oriented. If your plats are in North Azimuth, then in the first image the radial lines are oriented from the center point of the curve, towards the curve's points, whereas on the second curve they are oriented away from the curve's points towards the center. When entering information for radial lines using parcel editor, the orientation is expected to always be towards the center point of the curve. So, if changing plan settings to now use North Azimuth, it'd mean that the bearing on the first line entered, as annotated on the plan, is oriented away from the parcel and not towards the parcel, as I first thought, so that bearing would need to be reversed. Setup and entry for case1, using north azimuth would be: Setting the plan properties as follows: [ATTACH=CONFIG]23662[/ATTACH] Entry of the first 4 lines would be: [ATTACH=CONFIG]23663[/ATTACH] For the reversed bearing cases, if needed you can enter the value as shown on the line, and then use the Reverse Bearing command on the context menu: [ATTACH=CONFIG]23664[/ATTACH]
... View more
04-19-2013
08:53 AM
|
0
|
0
|
4350
|
|
POST
|
Hi Daniel, In the first case you can also achieve what you need without using the tangency. In the second case it looks like the image that you attached is cutting off information for the radial line bearings to the east where the dashed lines extend? Are there bearings on those lines? For your first case, I created a new Plan with the properties shown in the image below: [ATTACH=CONFIG]23632[/ATTACH] The settings under circular curves are the most relevant for your case. I'm assuming your bearings are all South Azimuth (0 degrees south)? I used south azimuth to match your image's orientation, and assumed north is straight up the page. South Azimuth is rare, so please only use this setting if you're truly working in South Azimuth. After making this new plan, you can add a new parcel into that plan, and enter it as follows: [ATTACH=CONFIG]23633[/ATTACH] There is also more information about entering circular arcs in this post: Dealing with missing traverse information in COGO -Tim
... View more
04-18-2013
09:53 PM
|
0
|
0
|
4349
|
|
POST
|
Dan, If, when the Job Book is opened, the default filter is to show "All" jobs, and if the jobs table has a lot of records in it, then that would explain the case that you're seeing. You can get around this by redefining the default job settings. To do this create an empty fabric in a file geodatabase, add it to the map, and then set the filter to show "Today" or specify a date range. This will reset the default filter, and so the next time you open the fabric with the large number of job records, the filter will present the filtered list. In terms of deleting Jobs of a particular age automatically, there is no ability to do that at present. That's a good idea. Please put it up for a vote on the ideas site. Thanks for reporting this. -Tim
... View more
03-12-2013
02:31 PM
|
0
|
0
|
460
|
|
POST
|
Halloween seems like the appropriate time to respond to the �??Dreaded Spiral�?�! Happy Halloween everyone! In tomorrow�??s Land Records meet-up, we will be doing a poll and discussion on this topic, (see examples in the documents attached to this post.) Since spirals often go hand-in-hand with Station-Offsets, and definition of a highway or road centerline, we�??ll cover stationing tools as well. Example (100+152.36, offset 10.00 left) Part of the poll is to determine if you ever encounter spirals and/or stationing and offsets while processing the parcel records at your organization, and if so how you enter or use them. For example, do you represent the spiral as a chord, like Betty? Or else do you keep older Esri ArcInfo software on hand to compute the spirals, as Bill does? �?�and so on. We are also interested to see if there is a geographic pattern to where spirals are referenced within recorded deeds and other land records. This will help us to learn if this is something that is more common on the US west coast, for example. We�??d like to hear from international customers too. Some of the meet-up poll questions may require longer answers, so if you are either not able to attend the meet-up, or would like to add further info on this topic, then please give us your feedback by responding to this post. Even something brief will be helpful, for example , �??Yes [/no], we do [/do not] need spirals and station offset utilities for managing our land records here in [organization], [department], [county], [state /province]�?� Thanks, -Tim
... View more
10-31-2012
02:31 PM
|
0
|
2
|
3654
|
|
POST
|
Jay, I've made this short video that should address your questions. It shows how you can use the over-rides to enter a circular curve with any combination of 2 geometry parameters and any of the 3 orientation parameters. You use these to by-pass the current Plan settings, described starting around [5:20] in the video, and I think that this also answers your question 3. In general if there is a straight line segment on a drafted plat/plan that: connects with a circular arc without an obvious bend where the 2 connect, there is no bearing for the curve shown in the curves table, (if there is a curves table) there is no bearing shown near the curve itself, or on either of the curve's radial lines, (if radial lines are shown) �?�then it can be inferred that for this pair of lines the circular curve is "running tangent" to the preceding straight line. Similarly, if the preceding line is also a circular curve, then you'd have a tangent curve that is running tangent to the preceding circular curve. When you create a tangent curve it is, by definition, never the first line that you enter for a new parcel or for a new construction. The term "tangent" is also used in a different context, and it can sometimes cause confusion; when referring to a "tangent bearing" for a circular curve this is referring to a property of the curve itself rather than to its tangency with respect to a preceding line. This is more fully described in the video, but the tangent bearing is one of 3 different bearing formats that may be used to define the orientation of a curve with respect to north, and it is not directly related to the concept of a "tangent curve." Hope this helps. -Tim
... View more
10-15-2012
09:43 PM
|
0
|
0
|
3088
|
|
POST
|
The grid coordinates are based on grid distances from the point of origin of the plane/grid defined by the projected coordinate system. In this case the lat/lon coordinate was used as a cross-check to confirm that the coordinates on the document are in grid. So to answer your question, yes: to convert the grid coordinates to ground coordinates you�??d apply the Combined Scale factor. Note that in the fabric (and for most typical projected GIS datasets) the coordinates for control are expected to be in grid coordinates, and the coordinates computed for the parcel points are also in grid coordinates. In the case of the document that you provided, the State Plane coordinates presented are in grid, because otherwise the lat/lon values shown in the Identify window as described in the previous steps, would not match the lat/lon values shown on the document. Since you�??re planning on working with the fabric, another important related note: all the distance values stored as attributes on the parcel lines are expected to be in ground distances; this is because distances placed on land record documents in the US are ground values. So for example, if you identify a line in the fabric, you�??ll expect to see the line�??s �??shape_length�?� to be different to the value in the distance field. The �??shape_length�?� is the grid distance. Please also see this archived thread on how the combined factor is used, relevant info quoted here: �??�?�a particular projected coordinate system (based on a particular geographic coordinate system) results in a plane, or grid. This plane may not align that well when working out in the field due to the average elevation or the distortions due to the projection. The grid coordinate are then scaled to better fit the local area.�?� -Tim
... View more
09-26-2012
09:21 AM
|
0
|
0
|
1953
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 09-18-2024 12:38 PM | |
| 4 | 09-18-2024 01:01 PM | |
| 3 | 04-26-2024 11:14 AM | |
| 1 | 04-04-2024 03:04 PM | |
| 1 | 02-15-2024 04:08 PM |
| Online Status |
Offline
|
| Date Last Visited |
Monday
|