|
POST
|
Hi Brandon, We fixed a bug at 10.1 that addressed a problem like the one you describe. This fix is also available on the latest service pack 5 for 10.0. If you are using ArcGIS Desktop 10.0 sp5 or later, and you'd created the topology while using 10.0 sp5 or later, then it is not the same issue, and we'll need to get more information to learn why it's happening. Please contact tech support if the problem persists. Thanks, -Tim
... View more
12-19-2013
07:50 PM
|
0
|
0
|
990
|
|
POST
|
Hi Ryan, There is this Add-in that gives some extended abilities to help you remove inconsistent records such as these. It includes a tool that lets you drag a box around the orphan points to delete them, and a utility accessed via the fabric context menu, that reports and optionally removes inconsistent records for the whole fabric. See also this thread about orphan points. Regarding your question about LGIM not showing features: you may need to calculate the Type for the particular parcel layer. For example, the Tax Parcels layer has the following definition query: (SystemEndDate IS NULL) AND ("Type" = 7) To make them appear, drag a new instance of the fabric's parcel class onto the map from the catalog window, start editing, and select the parcels that are to become tax parcels. Use the field calculator and assign the Type = 7 on the selection, then save your edits. You can then remove the extra instance of the layer you added, and those Tax parcels should now appear in LGIM fabric. Another approach would be to temporarily remove the definition query on the Tax parcels layer, make the same edit, and then set the definition query on the layer back to (SystemEndDate IS NULL) AND ("Type" = 7) -Tim
... View more
11-22-2013
01:13 PM
|
0
|
0
|
1184
|
|
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
|
856
|
|
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
|
990
|
|
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
|
1860
|
|
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
|
1818
|
|
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
|
1818
|
|
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
|
1860
|
|
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
|
1789
|
|
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
|
3607
|
|
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
|
1576
|
|
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
|
7833
|
|
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
|
7832
|
|
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
|
632
|
|
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
|
5277
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | a week ago | |
| 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 |
| Online Status |
Offline
|
| Date Last Visited |
yesterday
|