|
POST
|
Ben Thanks for offering this comment, but I am concerned that you feel the Overview records are junk and that the footprint layer is a mess. Perhaps the workaround you have described is acceptable to you, but if we can offer advice to improve the usability of your Mosaic Datasets, please let me know (you can contact me directly, or perhaps start a new thread listing your concerns) Thanks Cody B.
... View more
12-02-2015
01:52 PM
|
1
|
2
|
5500
|
|
POST
|
Brian - please let us know if this resolves your need. Based on your description, I am guessing that the 'Max Number of Rasters per Mosaic' property (as mentioned by Peter) can enable you to display the missing rasters, but I thought it would be worth a bit more explanation re: "Why?". re: 'Max Number of Rasters per Mosaic', we set a default of 20 to prevent poor performance if you attempt to view too many files. Yes, you can increase that value, and also adjust MinPS and MaxPS, but if you zoom out and expect to see hundreds of small images (requiring ArcGIS to open and display a large number of files) the result can be slow, especially if the source rasters don't have Pyramids. This leads to other key issues to consider, including the use of Pyramids and Overviews (the latter mentioned by Ben). If you aren't familiar w/ them, both are reduced resolution views saved on disk to speed display. Pyramids are associated with each source raster, and Overviews are conceptually the same, but associated with the mosaic of multiple rasters. In my 2nd paragraph I referred to opening hundreds of files - If pyramids do not exist, ArcGIS has to resample each raster on the fly to generate the proper resolution, and that will take time. But even if pyramids do exist, we don't recommend attempting to display hundreds simply because opening a large number of files will still take time (thus the default of 20 individual rasters). As Ben noted, when you zoom out, the system will automatically switch to displaying the appropriate Overviews if they exist. These are prebuilt reduced resolution views of the mosaic - so rather than displaying hundreds of individual rasters, you should have a very fast display of one or a small number of Overviews. I hope this explains why you see green wire frames rather than images. You called it a "typical problem" but this is how the system was designed, to avoid slow performance. (You might ask "well, why doesn't ArcGIS just do this automatically?" but think about the case of thousands or millions of images - users would be very angry if we automatically started a process to generate Pyramids and they had to wait for hours just to see if the images were in the right place -- thus the green wireframes) Two last notes: when you create Pyramids or Overviews, I recommend that you use Bilinear resampling rather than Nearest Neighbor, so the results look smooth. But no matter which resampling method is used, when you are working with raster versions of maps, at small scales you may find the view is not very useful. In that situation, I often recommend that you add a completely different dataset at an appropriate resolution (e.g. Landsat imagery, or a hillshaded terrain, or a 1:1,000,000 map etc.). It does not show your data, but it provides geographic context. If you would like to read more, we have published the Image Management Guidebook that provides discussion of all of these parameters. I hope this is helpful Cody B.
... View more
12-02-2015
01:43 PM
|
2
|
1
|
5500
|
|
POST
|
Ryan (As noted above) The initial release will be a standalone app, with increasing integration into the ArcGIS Platform in later releases. Cody B
... View more
11-13-2015
09:56 AM
|
0
|
1
|
1967
|
|
POST
|
Dan The Drone2Map app will require a separate license, but final pricing has not been determined. and Yes, users will be able to enter ground control points into the process Cody B.
... View more
11-09-2015
10:07 PM
|
1
|
4
|
3003
|
|
POST
|
Ahmad I thought I should clarify - it it is more than obtaining metadata for your images. In order for the mensuration tools to work, you must be working with original data from the sensor (satellite or aerial camera) - original meaning "not orthorectified". Depending on your data source, you may be able to get the unprocessed data. If the source is a satellite, the metadata you will need is encoded in RPCs (Rational Polynomial Coefficients) which typically will be available. You can then load the imagery into the map either using the Raster Product, or add the imagery to a Mosaic Dataset, using the specific Raster Type for the satellite. If using a Mosaic Dataset, you need to enable mensuration with a setting under Properties. If the source is an aerial camera system, you will need to have the camera model (interior orientation), as well as "exterior orientation" data (typically expressed as XYZ location and omega/phi/kappa orientation angles) for each image. You would then use the Frame Camera Raster Type to load your unrectified aerial images into a Mosaic Dataset (and again with the Mosaic Dataset, you must enable mensuration). Let me know if you need further information - Cody B
... View more
11-02-2015
04:40 AM
|
2
|
0
|
4147
|
|
POST
|
Bruce thanks for the more detailed info. I think I understand what you're doing, but this sort of modeling and data editing/creation is outside my expertise - I'll reach out to some others here within Esri and see if I can find an expert for you. Cody B.
... View more
10-15-2015
08:42 AM
|
0
|
0
|
247
|
|
POST
|
Nicola thanks for that interesting PDF. It appears the hyperlinks are no longer valid; have you already contacted Jennifer Carrell (the author) to ask about updates? If not, I'll ask and post the results. Thanks Cody B.
... View more
10-15-2015
08:31 AM
|
0
|
1
|
3193
|
|
POST
|
Bruce can you expand on what you are seeking when you say "correct" the overlaps? Do you need to change which is on top, or are you having problems where edges mismatch the underlying data? The Mosaic Dataset is specifically designed to combine rasters, even if they are at different resolutions and projections. The Mosaic Dataset (MD) is a virtual raster - a database table that points at your source files but does not copy the pixels - and it may or may not work in your groundwater flow model. But it has a number of options for deciding which pixels appear on top in areas of overlap - e.g. you can dynamically reorder the rasters by any available attribute (date, resolution, accuracy, etc.) and that may be of interest if you want to run your model with different rasters as "first priority". Or if you want to blend overlapping pixels etc. You did not mention NoData regions, but I'm wondering if that is a related issue you'd need to manage...? At version 10.3, ArcGIS added a function called "Elevation Void Fill" that provides an option to dynamically fill NoData areas if that is an interest. If your model cannot take a MD as input, I'd suggest you manage the various rasters in an MD and then once you have the overlaps properly addressed you can output a raster at any desired resolution & projection. If you could describe your data & requirements a bit further, and let us know your version of ArcGIS, we may be able to advise with more specifics. Cody B
... View more
10-14-2015
01:55 PM
|
1
|
7
|
3193
|
|
POST
|
Forest I thought I should summarize, although the post by Gabriel Upchurch summarized this pretty well – and your initial assumption [that this is caused by the inherent distortion of Web Mercator at high latitudes] was correct. I should have realized the details sooner. In the Web Mercator projection, the scale increases as (1/(cosine of Latitude)) so at 60deg it is 2x larger (2x scale error), and your data is at about 70 degrees latitude, so the scale error is almost exactly a factor of 3. Cosine(70) = .3420. That means it is a proper implementation for a Web Mercator projection that a distance of 100 meters will be reported to appear to be 300 meters. I had not realized this distortion would be embedded into a reprojected file, but it is necessary for compatibility with the coordinate system. Multiplied in 2 dimensions, this (3x3) distortio is a factor of ~9, so your input file (29 MB) becomes almost 250 MB after reprojection. This really emphasizes the disadvantage of using a projected coordinate system too far from its origin. If all of your work will be at high latitudes, it would be better to use a local coordinate system, assuming any measurements will be made on the map. Note I did some testing, and verified that the ArcGIS Online web map compensates for the distortion, so it provides generally accurate measurements. (Exactly how accurate, I do not know – I would need to ask our experts…) Also note that ArcGIS Desktop has options for how it reports measurements. It will default to "PLANAR" measurements when using the measure tool (which does NOT compensate for the scale distortion), but the tool has the option to choose "GEODESIC" which will provide accurate local measurements. Options to consider: The best option is to use the Mosaic Dataset to serve your imagery directly from its original format, and the application that consumes it can request any projection (AK State Plane, Web Mercator, other) and ArcGIS will project on the fly. For this, you will need our Image Extension, and I’m trying to confirm if your client already has it. The advantage is you won’t have to duplicate data on disk (either as export to Web Mercator *or* in raster tile cache format). Sub-option here – you do not need the image extension to serve one single image e.g. an orthomosaic of a single project site – but I’m guessing you have more than one site/one image and you would want to use a Mosaic Dataset & thus the Image Extension… If the web map needs to support measurements, consider building your web maps/apps in Alaska State Plane or another appropriate coordinate system. It is not mandatory for web maps/apps to use the Web Mercator projection, but that raises the question of what other data must appear in your maps… If you want to proceed with services using Web Mercator, I think they can be fine for visualization at Latitude 70 degrees (but at even more extreme latitudes I think the distortion would be unacceptable). If your users expect to make any measurements, you will need to consider and test the Web Mercator scale issues carefully. If you do proceed in Web Mercator, I’d suggest you cache directly from the Mosaic Dataset. The cache may increase in size due to the scaling, but you should use JPG format (assuming your images are continuous imagery or a hillshade of elevation data), and keep the scale changes due to the projection in mind – if you want the visual quality of a level 19 cache, you can actually start at level 18 (1/4 the data volume) and you won’t lose visual quality. Again, we should test a small area first to be sure! Note I had forgotten that your data file was 32 bit float. If this is elevation data, then the raster tile cache format is not usable – it is limited to 8 bits, 3 bands. We can share elevation data as a compressed 3D surface (different cache format), so if you need to share elevation values, this is a separate discussion. But note that using a dynamic image service, shared from a Mosaic Dataset, solves this…
... View more
10-12-2015
11:23 AM
|
3
|
2
|
4565
|
|
POST
|
Forest Got it - [disclaimer - text here has been edited to correct a misstatement I made previously] This may appear that Project Raster is in error but (as noted in my summary posted 10/12) it is actually honoring the definition of the Web Mercator projection which results in significant (but predictable) distortion at latitudes far from the equator. One note, have you tried directly generating raster tile cache from the source data? I'm now concerned that you're duplicating data twice (state plane --> web mercator --> cache). [another edit - raster tile cache is not suitable if the data is 32 bit (float) per pixel ] If you're not aware, you can generate cache using ArcGIS Desktop. We did a recorded webinar (accessible at this link Esri Training | Sharing Cached Imagery in ArcGIS ) that explains some of the details. Cody B.
... View more
10-06-2015
02:47 PM
|
1
|
1
|
1771
|
|
POST
|
Forest There is something fundamentally wrong, but so far I can't figure out what it is. Most of the dialogue above is correct - it's not a difference in compression or units - but the number of rows and columns of your output should not be dramatically different than the input. I can't figure out why that would happen. It almost seems like you have a custom projection, and something in that projection definition is confusing the software - e.g. it automatically figures out that 0.75 feet = 0.228 meters, but then when reprojecting, it "forgets" that the units are changing, so it's outputting 9 identical pixels for every single input pixel (oversampling from 0.75 units to 0.228 units of the *same* units). A few questions (although I do not believe that these explain the problem) 1) why are your rasters in a database? I typically recommend against that - rather, store as *.tif on disk and access them via a mosaic dataset. Is there a reason you can't do this? 2) Is there a reason that you MUST reproject and duplicate your data? If you use a mosaic dataset, you can project on the fly and not consume disk space or processing time... 3) have you reproduced this with other rasters, or is this one doi\ng something unique? If you could send me your input file - or a smaller one that is doing the same thing - I'd like to try to reproduce it. contact me for an upload link - cbenkelman@esri.com Cody B
... View more
10-06-2015
01:43 PM
|
1
|
3
|
1771
|
|
POST
|
Monica Sorry for the delay - Can you post some screenshots and describe this more fully? When you say "loses quality" do you mean the result is blurry or lower resolution? Or is the color changing, or perhaps brightness/contrast? And I assume you are starting your comparison with some other software - what are you FIRST viewing in, to say quality is lost in ArcGIS? Or do you mean if you look at ONLY the imagery in ArcGIS it looks good, but when you are using the same imagery as background in a map with other feature data THEN it loses quality? To determine if this is related to the Pyramids (reduced resolution views created to speed up displays), can you zoom to full resolution and let us know if that still looks good, but it's only when you zoom out that it loses quality? Thanks Cody B
... View more
09-23-2015
10:36 AM
|
0
|
0
|
639
|
|
POST
|
Just to complete the discussion re: ECW, MrSID and JP2: When working in ArcMap, we can read any of these formats. If you are seeking to OUTPUT an image file, ArcMap cannot write to ECW or MrSID. We can write output files in JP2 format. If you are seeking to SERVE the imagery via ArcGIS for server, we CAN serve either JP2 or MrSID we cannot serve ECW
... View more
09-18-2015
03:36 PM
|
1
|
0
|
2769
|
|
POST
|
I should note to Esin that I am not 100% certain about this. It should not take 1 hr 43 minutes to return this error, and your last line says "(When I create mosaic dataser from one topology map in the sam system configuration topology map can be published add image service and I can display it )" ...so it is possible you are running into another problem. Can you review your last sentence and tell us which types of image files are in the image service that DOES work?
... View more
09-18-2015
11:36 AM
|
0
|
0
|
2769
|
|
POST
|
Nicola I'm not sure I understand - are you saying convert ECW to MrSID? That is a similar problem - ArcGIS Desktop can read either format, but cannot create output files in either format (again a licensing issue). Perhaps you meant to say JP2, which would be very similar to MrSID, and that *IS* possible using ArcGIS Desktop, and the JP2 files could be shared through ArcGIS for Server. Given these two options, JP2 would likely result in a smaller data volume than Raster Tile Cache, but I have experienced performance problems with JP2. It would be best to test a small area, but assuming this is 3 band imagery, the Raster Tile Cache would likely be recommended.
... View more
09-18-2015
11:33 AM
|
0
|
2
|
2769
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | 11-20-2025 03:34 PM | |
| 1 | 02-07-2025 06:14 AM | |
| 2 | 05-16-2025 09:20 AM | |
| 1 | 05-16-2025 08:41 AM | |
| 7 | 02-26-2025 02:22 PM |
| Online Status |
Offline
|
| Date Last Visited |
2 weeks ago
|