Latest Contributions by MarcoBoeringa

�?� I search some addresses in the �??Al Irsal Street�?� and it works fine for the �??even�?� numbers and fails to find addresses with �??odd�?� numbers! What might be the issue here? ... �?� In return, in case of �??Al Sharafa Street�?� the system could search for both even and odd numbers. What might be the explanation? Jamal, I am beginning to think that the issue with the non-matching might be related to the "Side of the segment" field you referenced in the quote below. You are right it is not well documented what this actually is supposed to do. The one section in the Help describing it, leaves a lot to desire... However, I noticed you filled in "L" in the field for all records, and that seems to place the addresses next to the line. This is not the way Bruce described it, see the next quote below, where he talks of "Geocodes will land on the lines, not to each side." This may suggest that you need to leave the field "Side of the segment" empty, instead of filling in L. This is all a lot of speculation though, I hope Bruce can answer your question. It wouldn't hurt though, to try and leave the field "Side of the segment" entirely empty, instead of filled with "L's". I have created original data that fits the �??US Address �??One Range�?� address locator style that includes compulsorily fields for From Addr To Addr Side of the segment Street name 1. I couldn�??t figure out which data must be stored in the �??Side of the segment�?� field? You can achieve what you are looking for if you synthesize single-address ranges for your data.  First unsplit the roads based on street name and connectivity (Unsplit Line tool) then calculate start (0) and end (integer value of length in metres) 'address' fields onto the lines and use them as from and to address ranges.  Geocodes will land on the lines, not to each side. ... View more

[ATTACH=CONFIG]29061[/ATTACH] Please, consider that I�??m planning to publish the geocoding service by the ArcGIS server and then to plug it in my web application. The end user is assumed to provide the distance and street name and then the system is expected to zoom to that location. So for example, if the end user provides �??130 Al Irsal St�?� then the web application is supposed to zoom to that particular location as I have already illustrated. Jamal, just on a side note, but why are you using the Line option in the Linear Referencing tab in the dialog visible in the attachement / screenshot in above excerpt from one of your posts? Considering your requirement, that is, just one point location for a given address, you should be using the Point option. Line will return a line element, or zoom to the line as defined by the From and To M values, instead of the point address location (just M). ... View more

You can have a look at the below scripts though: �?� http://arcscripts.esri.com/details.asp?dbid=13428 �?� http://arcscripts.esri.com/details.asp?dbid=13886 It is doubtful if these tools will work in 10.x, since they were designed for 9.x, and the geodatabase system tables underwent major changes from 9.x to 10.x (conversion to XML based), most likely rendering the suggested solutions useless. ... View more

Hello!  I have a python script which reconciles all of our 72 versions in the recommended order, then compresses.  I notice, in the resultant log, that it reconciles "grandchild" versions with Default--not with the parent.  This is not consistent with my understanding of proper ArcSDE reconcile ordering. I would benefit from other ArcSDE folks' thoughts on these "grandchildren." Thank you! You may be mis-interpreting the significance of "reconcile order". In any batch reconciliation & post, there can be only one target version (as you set it on the dialog). It seems you set the DEFAULT as the target, hence all edit versions, including grandchild, grandgrandchilds and so on, will be posted against DEFAULT, not against each other based on child-parent version relationship. See also this recent discussion I had with another forum poster, where I initially made the same thought error in post no. 13, but corrected this in post no. 16: Sequence of reconcile/post from multiple versions to default ArcSDE geodatabase You may find reading the discussion in that thread (and also the links to (ESRI) documents and webpages about versioning in there) from the start a help in better understanding the process. By the way, "versioning" and "reconciliation" can be mind-boggling at times, and even if you get it straight once, you may get confused another time... it takes time to really familiarize yourself with all the details involved. ... View more

We were close to what I was looking for when using the US Address �??One Range�?� address locator style except one thing: sometimes, the odd values are not found ... What might be the issue? Why the odd numbers are not found? I have no explanation (yet), but have you tried the "Show all candidates" option on the Find dialog, and does it also fail to show any "candidate" address locations? ... View more

What I�??m looking for is a locator that reads the length and the name of the street such that if the value �??55 Al Irsal St�?�, then the system will locate it in its correct position in the street (55 meters from the start of the Al Irsal St) Jamal, this requirement of "distances" fitted on lines, although probably full fillable by Geocoding by manipulating the parameters, is actually not so much a "Geocoding" question (where you attempt to put addresses on lines), but a form of Linear Referencing or Dynamic Segmentation with Point events. See: What is linear referencing? Dynamic Segmentation For this to work in your case, the road names would need to determine what are the individual routes, and you set the begin and end "M values" like in my previous post. ... View more

Which address locator style can handle this scenario? Jamal, What Bruce suggests, is that you create "fake" From_Addr and To_Addr fields based on the length of the lines, instead of inserting real address numbers. - That is, the From_Addr field will in your case always be 0, use the Calculate Field tool to set it 0 if it already isn't. - The To_Addr will be the length of the road line, calculated by using the Calculate Field tool, and inserting a calculation statement like To_Addr = !Shape_Length! (when using Python) In order for this to work properly, and assuming you really do have distance measurement for each address, and that all road segments belonging to the same road (e.g. Al Irsal street) are measured continuously (distance measurements for addresses continue after a junction if still on the same road (e.g. Al Irsal street), than you need to make sure that "roads" are not split by junctions, but are physically continuing lines in order to calculate a proper To_Addr value (shape length). This is why Bruce reffered to the Unsplit Line Tool, a tool that merges individual line segment into one longer line based on a "dissolve field", in your case the road names. If instead, all of your measurements and roads stop at junctions (and roads that may continue beyond a junction have for example an individual index number (Al Irsal_1, Al Irsal_2, etc.), than you can probably skip using the Unsplit Line tool, and simply calculate the To_Addr field based on the existing lines' shape lengths. But this second option is probably less likely. ... View more

Hello Guys...I am new to the sde services provided by esri. I want to connect ArcCatalog 10.2 to my Oracle 11g R2 database using ArcSDE 10.2. I am using a 64-Bit Windows server 2008. If you are new to this and attempt to create a new geodatabase, it is highly recommended at this point in time to not use an ArcSDE Application Server and ArcSDE services, but instead use Direct Connect. ArcGIS 10.2 is the last release that will support the ArcSDE Application Server. See here: http://forums.arcgis.com/threads/83644-quot-The-ESRI-Geodatabase-Framework-quot-PDF?p=303021&viewfull=1#post303021 And this for more background regarding the difference between Direct Connect and an ArcSDE Application Server: http://forums.arcgis.com/threads/83644-quot-The-ESRI-Geodatabase-Framework-quot-PDF?p=295462&viewfull=1#post295462 ... View more

Hi Siva, I had this problem but now it works fine with me. Not sure what is the cause of this very frustrating issue. Best Jamal If you want to find out a little bit more about a possible cause of a specific geoprocessing error (in this case with errorno. 000582), than there is a less known section of the ArcGIS Help, that gives more background about each error-code, and may help in solving the issue: Understanding geoprocessing tool errors and warnings For this specific error, look here: 000582 : Error occurred during execution. In this case, it seems a rather in-specific error, still, checking the tools parameters and settings, might be in order... ... View more

1. My issue in this thread was to find a way to connect my GPS system with other tablet\laptop due to that fact that the touch screen of the Lieca CS25 is really irresponsive and made my life hard when doing few click. I wanted to replace it with other tablet (like Dell �??latitude 10 with windows 😎 so that I can enjoy doing my survey tasks. Did you actually manage to create a Bluetooth connection between your laptop and the GG03 antenna using the Zeno Field or Connect software on your laptop? The only other option to connect the GG03 to your laptop seems a dedicated type of cable, with a Lemo connector on one side (that connects to the GGO3, see these Leica specs for the GGO3), and a serial RS232 on the other side, see this link: http://www.surveyequipment.com/accessories/cables/leica-gev162-2.8m-gps-data-transfer-cable-lemoserial#.Un9K3OKp7kw Since most modern ultrathin tablets / laptops tend to lack this rather bulky and old type serial port, you will probably need a converter from RS232 to USB too, to be able to connect it to your laptop (The Leica CS25 is fitted with RS232 port according to the specs), like for example this one: http://www.startech.com/Cards-Adapters/Serial-Cards-Adapters/USB-RS232-DB9-Serial-Adapter-Cable~ICUSB232 ... View more

1. My issue in this thread was to find a way to connect my GPS system with other tablet\laptop due to that fact that the touch screen of the Lieca CS25 is really irresponsive and made my life hard when doing few click. I wanted to replace it with other tablet (like Dell �??latitude 10 with windows 😎 so that I can enjoy doing my survey tasks. By the way, is the tablet of the Lieca CS25 has a particular chipset that receives signals even without the GG03 Antenna? Brett answered your question already twice (and the specs of the CS25 also speak of it): If you are only using the internal SiRF GPS chipset, you can set your COM settings accordingly. The internal GPS of the CS25 unit is on COM 3, with a baud rate of 38400. So if your software was on the CS25 unit, you'd make the appropriate COM port and baud rate settings. 2. Then I moved to the accuracy issue. I got that the subscription is like $700/year (in Palestine) for the correction. Technically, how to check the current system on my Lieca CS25 machine (internet connection + GG03 Antenna): DGNSS\DGPS\RTK? And then is there a command that shows the level of accuracy that can be reached? I am not entirely sure, because I have never used the Zeno Field, Office or Zeno Connect software, but looking at the screenshot you yourself posted, I guess the Show GNSS Status menu option in the Zeno Field software will show the accuracy: Brett can undoubtedly guide you better here. ... View more

Hi Marco, I am following your instructions and thank you they have been very helpful.  Just a question, I already have ArcGIS for Desktop installed, do I need to uninstall then reinstall to get the option for step 7?  Right now, I am able to connect to my instance, but when I use the "new geodatabase" option then I get an error, so I wonder if it has to do with me skipping step 7. My license is "Advanced". [ATTACH=CONFIG]28981[/ATTACH] No, you shouldn't be forced to completely uninstall and re-install ArcGIS for Desktop (at least not with the ArcGIS for Desktop 10.2 install part of the ArcGIS for Home Use program, on which I based these instructions) in order to get this option of enabling the SQL Server Express database to store a geodatabase. It looks like the enabling of the database for storage of a geodatabase failed, and hence you can not use the New Geodatabase option successfully. A couple of questions: - You did see the option "Enable geodatabase storage on SQL Server Express" listed in the dialog I referenced in step 7)?? - You did perform step 4-10, including 7? You seem to suggest you skipped those. You MUST perform these steps, because it is exactly in those steps, that you enable / license the SQL Server database to store ESRI Geodatabases. If you don't perform these steps, the New Geodatabase option will fail, because you are not licensed yet to create the geodatabase (which is exactly your error message). - You are using SQL Server Express as the backend database, do you? Not an enterprise class SQL Server database? These instructions are for creating databases in SQL Server Express, not an enterprise class SQL Server database. *** EDIT *** I am realizing your main confusion is about the ArcGIS for Desktop installation needing to be started at step 4). The ArcGIS for Desktop installation actually consists of multiple independent modules, and the ArcSDE for Microsoft SQL Server 2008 R2 Express option is one of them. So even though you must start the ArcGIS for Desktop installation at step 4), this doesn't mean you need to re-install entire ArcGIS for Desktop to enable geodatabase storage. In fact, you just have to choose / run the module for the ArcSDE for SQL Server Express installation, as described in steps 4-10. This option is available straight from the main installation window that opens once you start the installer. And even for this module, you will bail / opt out of the SQL Server 2008 R2 Express installation, as described in step 7), just continuing to enable / license your existing SQL Server 2012 Express in steps 7-10 (assuming you do pre-install V2012 as in step 1). ... View more

I couldn�??t figure out: 1. The accuracy of the measurement 2. How to connect it with reference station to improve the accuracy If I look at the product folder for the GG03 here, it says that for the "integrated real time" SBAS correction (Satellite Based Augmentation System), your accuracy is about <0.9 meter. With correction against a known, surveyed, reference station as in DGNSS (Differential Global Navigation Satellite System), also called DGPS, you should achieve around 0.4 meter, depending on the distance between your reference point and the location where you are surveying. Lastly, with RTK, you should be able to get down to less than a decimetre, up to 1 cm. So, without tying yourself to any ground based reference point as in DGNSS or RTK mode, you will have about 1 meter accuracy at best. Please note that for both DGNSS/DGPS and RTK, you need to be able to contact a known reference station. A lot of countries have government or commercially maintained reference networks for this, with fixed GPS receiver base stations broadcasting their positions and corrections (CORS - Continously Operated Reference Station). This may be a paid service in your area. I don't know if Palestine has its own CORS network?, but these articles might be interesting for you: The Permanent GNSS Network and its RTK Application in Israel http://www.fig.net/commission5/wg52/ts01c_salmon_3248.pdf Permanent GPS Network-based Measurement Practice in Israel http://www.mapi.gov.il/UsefulInfo/MapiPublications/FIG2009_forrai_3496.pdf As Brett says, some training might be in order... *** EDIT *** And as to the question how to connect to a CORS station, see these texts from the Wikipedia page about RTK: "There are several ways to transmit a correction signal from base station to mobile station. The most popular way to achieve real-time, low-cost signal transmission is to use a radio modem, typically in the UHF band. In most countries, certain frequencies are allocated specifically for RTK purposes. Most land survey equipment has a built-in UHF band radio modem as a standard option." "A Continuously Operating Reference Station (CORS) network is a network of RTK base stations that broadcast corrections, usually over an Internet connection. Accuracy is increased in a CORS network, because more than one station helps ensure correct positioning and guards against a false initialization of a single base station." ... View more

Here is the issue I am seeing. I can create a spatial view and it renders fine in catalog and ags. But if i modify the sql OR if a situation arises that makes my view devoid of records then all of the sudden sde and ags get really 'stupid' and have no clue what my geometry type or coord sys are for that view. Am i to believe that a spatial view MUST always have at least one record in it? Yes, it does, like Shannon wrote. Is it too much to ask for the metadata to be gathered from the only spatial column present in the base table? It probably is. The answer we are getting now is to use the command line tool to create the views and make sure they are registered with sde. Apparently with the new style views the geometry metadata is gathered on the fly from the first record in the table. That makes sense to me. But what about when there are no records? Seems like a better system would have been to get the metadata from the only spatial column in the view - the one in the base table - which is a feature class. A feature class can be empty and sde/ags still knows it is a feature class. One could argue that the collection of metadata on the (potential) first record in a view as opposed to the true metadata in the (singleton) spatial column of the base table that was the progenitor of said view is synonymous with proprietary software manufacturer laziness. I don't agree, I think you are heavily underestimating the consequences of the task you are requesting ArcMap to do, that is, to determine the feature type of a spatial view or Query Layer with no records in it, and not pre-registered with ArcSDE or the geodatabase, based on an evaluation of the SQL expression and digging down to extract information from the base table. As Vince wrote: In your particular use, registration of the existing view is necessary (it is not possible for a query cursor to mine the database query plan to extract the information you expect it to have), but that only requires 'sdelayer -o register', not recreation of the existing views (be sure to use 'sdelayer -o describe_long' to extract the SRID of the base table for the -R flag in the register options). The underlined and bold sentence may sound a bit cryptic, but to make the argument more clear, you have to realize that database views or Query Layers offer maximum flexibility. You can insert / use any valid SQL expression your RDBMS supports, with just a few unsurprising restrictions outlined here if the data needs to be used straight in ArcGIS via Query Layer as well. This flexibility comes at a price though... While your particular "case" might seem straightforward, with probably a single base table, no joins, no GROUP BY, SUM, AVG, COUNT, no spatial type conversion or whatever particular ANSI/ISO SQL DML, or database SQL spatial type, statement one can use (E.g. ST_Intersection, ST_Centroid), users in practice may make use of any of these options. The result of this is a whole bunch of "headaches" coming up once you dig down these kind of SQL statements. The one that probably hurts most in the context of your arguments, is that it also means that users will be able to even perform "feature type" conversion on the fly. Yes, that is, to convert a Polygon base table to for example a respective centroid "Point" type spatial view or Query Layer based on a spatial type SQL statement like ST_Centroid, or, as another example, a "Polyline" layer representing the outlines of the original polygon features. I guess I don't have to explain to you for this particular example involving feature type conversion, that the result of a dig down to the base table, won't result in anything useful that would solve your issue... An example of such type conversion in a recent thread here in the Geodatabase & ArcSDE forums: Registering a polygon table to point in a m. view using SDO_CENTROID/sdelayer error Since there are marked differences in the implementation of (spatial type) SQL for each database ArcGIS supports, the headache becomes even bigger. Another major issue is that views could be based on other views in the database, requiring a recursive operation as well to find that elusive "spatial column"... I really think your issue is more of a workflow / application design issue. You chose spatial views, while in practice, you require geodatabase functionality, or at least registration of the layers with the ArcSDE system tables. Anyway, if you want changes to ArcGIS that accommodate your particular "simple case", you are probably better off posting an enhancement request in the ArcGIS Ideas website. And as Vince wrote: Hopefully, there will be a ArcPy tool that will register views with geodatabase metadata once that which was once ArcSDE is gone. It seems likely such a tool will be part of a future release of ArcGIS. And ESRI is making a serious request to us all to state issues regarding the deprecation of the ArcSDE Command Line tools, and the need for ArcPy or Arctoolbox user interface replacements. You could list your issue in this sticky thread as well: Alternatives to using SDE command line tools - Blog Discussion OK, just noticed you posted a response at the blog as well 😉 ... View more

The dichotomy of the the two different interfaces has always been the issue. If there's no command line and no API to make a command line, then the geodatabase takes over full ownership of all tables owned by the SDE user. At that point, your suggested change is a distinction without a difference. The "SDEish" metadata tables have always been geodatabase metadata tables in fact, so I don't see any major change. X2, this was how I viewed it, but I was just wondering if any new major changes to ArcSDE (/ Geodatabase) Repository were due. I guess any future changes will be pretty much inconsequential for anyone sticking to official APIs like ArcPy, ArcObjects, just like the change to XML based tables for the geodatabase system tables at 10.x, as the APIs pretty much hide what is "behind the scene"... ... View more