POST
|
Your cert was issued from a internal CA and it is not trusted, so you need to import the root for your internal CA into the cert store used by arcgis monitor. Many of the more common root CA are already preinstalled in the cacerts file. You can use keytool.exe in the folder C:\ArcGIS Monitor\framework\runtime\jre\bin to see what root certs are pre installed and explore some other things. Lots of documentation on this tool. Step 1 Export the root cert for your internal CA from your browser to C:\temp\PKICorpRootCA.cer. the export file format should be Base 64 encoded x.509 These are the ROOT CA I have as shown in Chrome browser You could also just export the root CA to file from the certification Path *******SDCP01-CA you show in you initial posting. Whatever works for you. Example to import the root cert from the file C:\temp\PKICorpRootCA.cer from your internal CA: cd C:\ArcGIS Monitor\framework\runtime\jre\bin keytool -import -trustcacerts -keystore "C:\ArcGIS Monitor\framework\runtime\jre\lib\security\cacerts" -storepass changeit -alias pki_root -file C:\temp\PKICorpRootCA.cer Thats my guess!
... View more
08-17-2020
06:09 PM
|
0
|
0
|
909
|
POST
|
I have the same problem with RMDs 10.0. The only way I have to update the reference is to recreate the refrenced Mosaic Dataset and the function chain in the target Geodatabase after I have copied the base Mosaic Dataset.
... View more
11-14-2011
07:51 AM
|
0
|
0
|
304
|
POST
|
I was having issues getting "import gdal" to work also. Some stuff going on with the python environment in ArcGIS 10. I ended up getting gdal working with python 2.6 (not from within ArcGIS desktop). Once I got that working I then copied the gdal16.dll(not the dll installed with ArcGIS) to the C:\WINDOWS\system32 folder and now I can import gdal from the python interpreter instantiated from within a ArcGIS desktop application. I really don't know what is going on here but It must have someting to do with the unique way ArcGIS 10 pooling a single instance the python interpreter to be to be shared with all Python based GP tool calls and how this environment is being setup. I noticed the IDLE IDE interactive command window has the line "IDLE 2.6.5 ==== No Subprocess ====". I have never seen this before and is maybe a bit of a hit of how the interpreter if fired up by ArcGIS 10. Wierd stuff! If anyone has some insight, please share it.
... View more
06-24-2011
06:09 AM
|
0
|
0
|
679
|
POST
|
Hi, I am working with Mosaic Datasets in ArcGIS 10 Is it possible to enable attachments on the footprint feature class in a Mosaic Dataset to support linking of multiple documents to each source dataset footprint. I have used a relationship class and a seperate table with hyperlinks, but it requires a copy of the footprint feature class be exported and a primary key for defining the 1:M relation be maintained in the featureclass. Is there any detailed documentaion specific to the columns in the footprint featureclass? Thanks
... View more
02-15-2011
12:05 PM
|
0
|
2
|
3263
|
POST
|
I have similar issues. My solution was to write a geoprocessing script tool in python using GDAL and lxml. My approach was as follows to use tiff files with embedded GDALMetadata Tags 1. read the service table to get the location of the relevant rpdef 2. read the rpdef to get the location of the raster source file 3. extract the "IMG_GUID" attribute from the GDALMetadata xml embedded in the tiff file 4. add the GDALMetadata element to the .rpdef for each raster found and store the IMG_GUID value(ie. /ImageServer/RasterProcessDefinition/Rasters/Raster/AdditionalFormatInfo/metadata/GDALMetadata) 5. Delete all PAM elements (persistent auxiliary metadata). I have had some issues with the image service editor if this element existed in the rpdefs 6. Delete all references to Tag_42112 I the tiff files have associated .tif.aux.xml files the behavior is a little different when you add a raster to a service, below is an example of PAM stored in a .tif.aux.xml file. I have based my design on this behavior so I can support all raster formats even if they do not support internal metadata storage. <PAMDataset> <Metadata> <MDI key="EVENTID">40d7aac1-d410-49b9-9b25-faeab1d85bfb</MDI> </Metadata> <PAMRasterBand band="1"> <Metadata> <MDI key="LAYER_TYPE">athematic</MDI> </Metadata> </PAMRasterBand> </PAMDataset> It appears if the rasters have associated .tif.aux.xml the behavior is more consistent. so I guess you could create a .tif.aux.xml for all the raster sources. Make sure you have deleted the .aux files that some times get created automatically by ESRI applications or you may get alot of additional metadata added to the rpdef that is not wanted. Below is an example of clean well structured metadata element that has worked for me <metadata> <srs format="OpenGIS">PROJCS["NAD83 / UTM zone 10N",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 1980",6378137,298.2572221010002,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4269"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-123],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AUTHORITY["EPSG","26910"]]</srs> <compressionmethod>none</compressionmethod> <recommendedbackend>tiff</recommendedbackend> <geokeys> <GTModelTypeGeoKey>geokey:S:1</GTModelTypeGeoKey> <GTRasterTypeGeoKey>geokey:S:1</GTRasterTypeGeoKey> <GTCitationGeoKey>geokey:A:"NAD83 / UTM zone 10N"</GTCitationGeoKey> <GeogCitationGeoKey>geokey:A:"NAD83"</GeogCitationGeoKey> <GeogAngularUnitsGeoKey>geokey:S:9102</GeogAngularUnitsGeoKey> <ProjectedCSTypeGeoKey>geokey:S:26910</ProjectedCSTypeGeoKey> <ProjLinearUnitsGeoKey>geokey:S:9001</ProjLinearUnitsGeoKey> </geokeys> <geopixelscale>2.000000000000, 2.000000000000, 0.000000000000</geopixelscale> <geotiepoints>0.000000000000, 0.000000000000, 0.000000000000, 566557.000000000000, 6633521.000000000000, 0.000000000000</geotiepoints> <TIFFTAGS> <GeoPixelScale count="3" type="float64">2.000000000000, 2.000000000000, 0.000000000000</GeoPixelScale> <GeoTiePoints count="6" type="float64">0.000000000000, 0.000000000000, 0.000000000000, 566557.000000000000, 6633521.000000000000, 0.000000000000</GeoTiePoints> <GeoKeyDirectory count="32" type="uint16">1, 1, 0, 7, 1024, 0, 1, 1, 1025, 0, 1, 1, 1026, 34737, 21, 0, 2049, 34737, 6, 21, 2054, 0, 1, 9102, 3072, 0, 1, 26910, 3076, 0, 1, 9001</GeoKeyDirectory> <GeoASCIIParams count="1" type="string">NAD83 / UTM zone 10N|NAD83|</GeoASCIIParams> <GDALMetadata count="1" type="string">...</GDALMetadata> <GDALNoDataValue count="1" type="string">-9999</GDALNoDataValue> </TIFFTAGS> <GDALMetadata><Item name="EVENTID">c5ee467e-8893-495d-82ac-28e289c94dc3</Item></GDALMetadata> </metadata> GDALMetadata(tag 42112) and GDALNoDataValue(tag 42113) are registered tiff tags, similar to the GeoTiff tags hence they show up under the <TIFFTAGS>, not sure why GDALMetadata tiff tag is being parsed as an unrecognized tiff tag in one of your examples. It�??s a bug I guess! I consider "<GDALMetadata count="1" type="string">...</GDALMetadata> " as valid. GDALMetadata is an attribute of the <TIFFTAGS> indicating the number of xml strings, hence the use of the ellipsis. Just my interpretation! I also notice you may not have defined a GDALNoDataValue, I know support for nodata in image server today is very weak, but in the next release I think ESRI has added allot of new support for the concept of nodata. Just an observation!
... View more
06-03-2010
08:41 AM
|
0
|
0
|
344
|
Online Status |
Offline
|
Date Last Visited |
06-16-2023
09:25 AM
|