Latest Contributions by HardolphWasteneys

Recreational GPS devices do this, but I have no idea how you would find out the code they use.  The definition of the UTM zones is simple enough being a standard 6 degrees of longitude (unless you go to MTM 3 degree zones) so your app could query the longitude and make the jump as it crossed a zone boundary or better display something that showed continuation of coordinates in the previous zone and ask the user if they wanted to jump. what kind of device? Hardolph ... View more

Eric, I'll have a look at the data later today when I get back to my GIS machine.  If the Resource Center imagery is clear enough, make the parcels show just outlines and you might be able to get a better feel for which shapefile is more accurate.  One presumes that more recent photo coverage and mosaicing should be more accurate than older stuff that might not have been set up for the world of GIS parcel fabrics. Given the precision you need for this, and the available resolution on the Resource Center you could go back to overlaying both shapefiles in Google Earth, but make the parcel polygons clear so you can see alignment better.  The May 2010 GE image looks high enough resolution to draw from itself as you can see sidewalks and fence lines.  Another essential place to check would be with Pembroke city engineering for CAD drawings based on surveys. You'd have to georeference these dxfs in ArcMAP by finding two unambiguous points for which you have independent coordinates.   The photomosaic/orthophotos will have ground control points with precise coordinates and you could also cross check those both against the display in ArcMap and in Google Earth to see if there is any glaring discrepancy assuming the GE imagery is correctly georeferenced.  Overall you are trying to check the veracity of the new orthophoto mosaics; from what I can see the new digitizing is good relative to them.  So the 3 to 5 m shift you measured relative to GE spot locations in the new shapefile (and presumably imagery) is cause for concern.  GE imagery might be off by that much, but the city engineering drawings will not.  Another independent check would be some GPS coordinates of distinct features on the new orthophotos, but those would have to be taken with a sub meter unit (e.g. Trimble GeoXT) not just a recreational one (e.g. Garmin Map60CSx).  If it came to that you could also have the control points checked, but I would not hold much hope that they were inaccurately measured.  Maybe a wrong transformation from WGS84 to NAD83, for the control point file, but that would not account for much. Meanwhile one thing I noticed that might help with the connection problem is that you seem to have a space in the name of the personal geodatabase in C:\Drawings\Pembroke2\Pembroke DB.mdb, which is not advisable.  If so, good idea to either rename or copy contents to a new one.  Also, I generally no longer use .mdbs in favour of file geodatabases after finding problems with them moving from an XP platform to Win7, but I don't think that is a cause of the connection problem. Hardolph ... View more

Hi Eric, had a closer look at the clips of the shapefile alignment on the orthophotos.   Looks to me like there is no problem with the coordinate systems, but more of  disagreement between the old digitizing and the new orthophotos and shapefile.  The new shapefile appears to be redrawn completely from the orthos (I assume that is what is displayed below)so various small shifts may have something to do with the mosaicing of the photos relative to the old ones.   May be a case where the old shapefile was drawn from less accurately aligned photos. Do you have the old photos to compare with the new?  How about the alignment with Resource Center imagery? Hardolph ... View more

Eric, there are quite a few choices in the Resource Center for different types of imagery, topo etc that provide good coverage outside the US.  I'd start there again and see if you can come to some resolution about the 2 files. Hardolph ... View more

Eric, The magnitude of the displacement is typical of an incorrect GCS transformation, but to confuse that you mention that the displacement is variable. Also, I'm not sure what you mean by "Both shapefiles are projected on NAD 1983 in zone 18N": do you refer to the Data Frame projection or the CRS of the files as shown in layers Properties > Source or in ArcCatalog under the shapefile Properties XY Coordinate system?  If they are the same CRS then the GIS source has made some error in the new file or corrected some error in the old.  If they have a different Geographic Coordinate System then look at Transformations in the Data Frame Properties and make sure the correct one is set for transforming the GCS of the new layer to that of the Data Frame and presumably of the original layer. The other question is:  how do the shapefile line up against some reference like one of the "Add Data from Resource Center" maps in the main ArcMap  menu under "File"?  This is usually a good test especially in high precision areas of the eastern seabord and southe Canada and more convenient than importing the shapefiles into Google Earth or indirectly comparing a few spot coordinates.  If you can post the CRSs of the two files and a screenshot of their alignment relative to the Resource Center maps that would help clarify the problem. Hardolph ... View more

Raphael and Kevin, you might want to look into Linear Referencing; Create Routes from your streams that have a direction based on a starting spatial orientation priority that overrides the digitized direction of the input features in the polyline segments. http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Using_existing_linear_features_to_create_routes Here's a few threads about using Linear Referencing for stream problems and directional markers. http://forums.arcgis.com/threads/58826-Show-Direction-of-Route-with-Arrow-Symbol?highlight=Hardolph http://forums.arcgis.com/threads/4302-Calculating-river-distance-from-one-point-to-another?highlight=Hardolph that would definitely overcome the specific problem you are referring to but may lead into deeper waters when you see what else you can do. Hardolph ... View more

Michael and Mark, yes, it is an outstanding issue. Here are the recent threads you were looking for: http://forums.arcgis.com/threads/57598-Overlapping-Data-Frames-in-the-Layout http://forums.arcgis.com/threads/52636-Clip-data-frame-why-is-original-shape-still-appearing Not just transparencies, but also rasters and picture markers in the layout will override the clipped margin. Hardolph ... View more

Jose, This is easy enough to do without Model Builder using the CreateFeatureFromTextFile script in the ArcGIS 9.3 Toolbox Samples. http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=Create_Features_from_Text_File_(Samples) It can be devilishly tricky to get the formatting correct, but once you understand the key formatting parts it is straightforward and useful in many situations not only where you are starting with a text file of points, but also in converting between polyline, point and polygon shape formats in many cases simply by changing the header (e.g. "Polygon" to "Polyline"). For a polygon the key aspects of the text file are like those in the pasted in file below (and attached), including repeating the first point at the end of the cycle of coordinates in the table for the vertices to close the polygon. The example below is a Polygon with ZM coordinate set to 0.0 and with an "interior ring" created from the shapes shown in the polygon8 image using the WriteFeaturesToTextFile script; also in Samples. If you are going straight from a spreadsheet writing the coordinates from just make sure you clone the general formatting shown (delete the interior ring and its vertices) including ensuring that you have no hanging spaces at the ends of lines. [ATTACH=CONFIG]14712[/ATTACH] Polygon 0 0 0 11.7058615641 5.47888198704 0.0 0.0 1 11.4280287533 5.20104917628 0.0 0.0 2 10.8723631318 5.23577827762 0.0 0.0 3 10.2430826009 5.16676875696 0.0 0.0 4 9.80468260089 6.12200515696 0.0 0.0 5 10.334062061 6.4512968247 0.0 0.0 6 10.1083229022 7.05905609824 0.0 0.0 7 10.3514266116 7.12851430094 0.0 0.0 8 10.7508112771 7.16324340228 0.0 0.0 9 11.1849250439 7.14587885161 0.0 0.0 10 11.9836943749 6.92013969286 0.0 0.0 11 12.0734890575 5.69610103077 0.0 0.0 12 11.7058615641 5.47888198704 0.0 0.0 InteriorRing 13 10.4035202636 5.70462114578 0.0 0.0 14 10.8897276825 5.63516294309 0.0 0.0 15 11.6711324627 5.89563120318 0.0 0.0 16 11.497486956 6.15609946327 0.0 0.0 17 11.2022895946 6.36447407134 0.0 0.0 18 10.4035202636 5.70462114578 0.0 0.0 END Hardolph ... View more

Yes. The distance between any two points will be correctly calculated using the tool when the data is in a GCS and the Data Frame as well.  It is just measuring the arc length on the earth surface. However, if you try to calculate any geometric properties of the features such as length (of a curving polyline) or area in a non-projected Data Frame you will find the functions disabled and get the message in the clip below that all calculations are done using "planimetric algorithms".  [ATTACH=CONFIG]14667[/ATTACH] You can check the distance aspect further by drawing a circle in a GCS Data Frame in a file with either a projected or geographic coordinate system (i.e. not using the graphic tool)and see the measured difference between the N-S and E-W diameters using the measure tool, the ratio of which increases at higher latitudes.  To see the GCS circle change shape in a Projected Data Frame use the generalize tool on it to make it into a series of points (offset .001 or something; or it will just recalculate as a curve into a new circle).  Then shut off editing and change the coordinate system to a projected one appropriate for the range of the data and observe N-S stretching and graphically correct diameter measurements. I'm not quite sure what you mean by: "Since I don't know what the coordinate system of my data is, I cannot set up a good map scale on a layout as ArcMap doesn't know what units the coordinates are using". , but you can project the GCS data into any Projected CS you want for your layout, otherwise it will look flattened N-S. hope that explains it well enough, Hardolph ... View more

Misti, sounds like you have some additional complexity in one of the features that is making for calculation difficulty or an extremely massive feature and something else happening. I'd suggest running Data Management > Features > Check Geometry on both features and run the companion Repair Geometry tool on them as well. If either tool shows or does anything that's likely the cause of the hang.  You might have some self intersecting loops.  Generally these fault just cause the tools to crash or create no output.  Hardolph ... View more

Samantha, it does not go to the coordinates because you have reversed the inputs:   Long: = -97.080497  (the X coordinate) and Lat: = 33.155781 (the Y coordinate). The Go To tool does not "know" that you have reversed them, but there is no latitude -97.080497 or anything above -90 for that matter in degrees, so it just sits. [ATTACH=CONFIG]14279[/ATTACH] Hardolph ... View more

Samantha, for the Go To X-Y tool with the coordinates as shown you need to change the entry format to "decimal degrees" by clicking the small drop down arrow on the right end of the toolbar.  You have it selected for "degrees minute seconds" which would look more like 98 33 22 W for X and 35 48 27 N for Y in the entry windows. Hardolph ... View more

Derek, Look into Map Topology  http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=About_topology Hardolph ... View more