|
POST
|
Hi Daniel, you are going to have to run one of the genearalizaion tools after creating your linework. Once you have an acceptable result your labelling should be fine. As far as your grid cell sizes are concerned, you need to consider things such as your minimum mapping unit and extent.
... View more
09-09-2014
09:00 AM
|
0
|
0
|
2974
|
|
POST
|
Thanks Kelly et al- I ended up borrowing the home_locate.png from arcgis online at http://cdn.arcgis.com/cdn/4922/js/esri/arcgisonline/map/css/images/home_locate.png Then, I just created a simple on load function and added Robert's code:
//on function for home button slider
mapMain.on("load", addHomeSlider);
function addHomeSlider() {
//let's add the home button slider as a created class, requrires dom-Attr
dojo.create("div", {
className: "esriSimpleSliderHomeButton",
title: 'Zoom to Full Extent',
onclick: function () {
if (extentInitial === undefined) {
extentInitial = mapMain.extent;
}
mapMain.setExtent(extentInitial);
}
}, dojo.query(".esriSimpleSliderIncrementButton")[0], "after");
}
Since I'm not utilizing a progress bar for this app, I excluded the code for displaying the status bar message. I then modified the css:
.esriSimpleSliderHomeButton {
border-bottom: 1px solid #666666;
background: url(../css/home_locate.png);
background-repeat: no-repeat;
}
.esriSimpleSliderHomeButton:hover {
background-color: rgb(102, 102, 102);
background-color: rgba(102, 102, 102, 0.9);
}
Which produced this nice clean look:
... View more
09-03-2014
02:38 PM
|
2
|
0
|
3441
|
|
POST
|
Right, thanks Ken. I thought I could pull it out of my downloaded api somewhere, but this will work too. Thanks for the data URI tip...
... View more
09-03-2014
12:52 PM
|
0
|
2
|
3441
|
|
POST
|
Hi Robert- Can you tell me where in the api you are pulling the home slider png?
background-image: url(../images/zoomExtent.png);
... View more
09-03-2014
12:39 PM
|
0
|
4
|
3441
|
|
POST
|
Hi Peter- If you want to apply something like a Fast Fourier Transformation you will probably have to set up and run the appropritate Spatail Analyst Math tools to create an FFT algorithim, a difficult task in ArcGIS but easily performed in ERDAS. In looking at your example though, I don't think you are dealing with an image anamoly, but rather a processsing anaomly created during a merge as you suggest, as such an FFT wouldn't necessarily be appropriate. I would try using the Majority Filter tool (essentially a high-pass filter) first, changing the input paramters for neighbors and definition unitl you produce a reasonable surface.
... View more
09-02-2014
08:02 AM
|
1
|
0
|
959
|
|
POST
|
Good one Robert, I'd been looking for this one for some time myself- Thank!
... View more
08-26-2014
02:20 PM
|
0
|
0
|
3441
|
|
POST
|
There's something going on with the algorithm. I'm getting the same thing. A very simple case below shows a label layer applied to a half-township section grid. I am also at 3.10 and still get missing labels, regardless of various parameter changes I've applied
... View more
08-25-2014
12:10 PM
|
0
|
0
|
1683
|
|
POST
|
Well, there's not much to tell. Prior to our move to SQL Geometry at 10.1, I found that for certain utilities feature classes like hydrants, there would be from time to time more rows in the business table than in the feature (f) table. I discovered that nugget as I was transforming data into Intergraph format via FME. I didn't even think it was possible to create or otherwise load rows into a feature class using standard ArcGIS front-end methods and not create geometry, but it happened. So it's not a primary key error per say, it's more of a key-constraint violation I would guess. What I suspect had happened is that hydrants data, coming in from an xy event table created from a spreadsheet perhaps had inverted x,y's or were perhaps in a differenent coordinate system, or had differenent units. But because we use well-defined x,y domains, resolution and tolerances I think the information was added to the A and F table but upon, reconcile, post and/or compress, the invalid values in the F table were dropped, but the business rows remained. That's my theory.
... View more
08-25-2014
09:51 AM
|
0
|
0
|
1805
|
|
POST
|
Hey Dave, I had something like this awhile back before we moved over to sql geometry, only in reverse to what you describe, i.e. more business records than geometry. It was happening because certain editors were copying and pasting records from spreadsheets in a way that was violating the key constraints. Basically I set up sql scripts to remove the dups and clean any and all dependencies in both directions. I've got some scripts somewhere, I'll see if I can round them up if you don't have this solved-
... View more
08-21-2014
09:05 AM
|
0
|
2
|
1805
|
|
POST
|
Hi Aaron- We have found that hyperthreading on the CPU must be disabled whether running SQL2008 or SQL2012 when using sql geometry, but not when using binary storage. We lost nearly half of our performance until disabled. We also found immediatly that spatial indices matter greatly with sql geometry, especially for complex polygon datasets like a parcels layer. The default grid levels(med x 4) and cells per object (16) did not perform well for us at all. After disabling hyperthreading, we set up our dbTune with index levels of (med, med, med, low) with 64 cells per object. We arrived at this level through trial and error as there still doesn't seem to be any effective guidelines- performance has been acceptable since. I had started a similar thread here, SQL Server 2012 and 2008: Geometry Performance - that asks if there are any performance gains when moving to 2012. SQL Server 2012 and 2008: Geometry Performancehttps://community.esri.com/message/96614#96614 It's been viewed just a scant 23 times with 0 replies, although this post appears to have done just that- Thanks David
... View more
08-21-2014
08:17 AM
|
7
|
0
|
4984
|
|
POST
|
Wow Jeff, you didn't have to do this, but thank you.
... View more
08-19-2014
12:37 PM
|
0
|
0
|
782
|
|
POST
|
Thanks for putting this up Jeff. Michael and I are trying to utilized the side panel popup to hold the results from a gp model that is returning fetures and graphics based on the linear distance from a selected feature, basically a select by attribute of an input layer then re-selecting user-input features base on a linear extent
... View more
08-19-2014
11:41 AM
|
0
|
2
|
782
|
|
POST
|
Thanks Matt- Oh sorry all I did mean RECREATE_ALL_TILES, not UPDATE_EXISTING_TILES in my earlier post
... View more
08-18-2014
09:17 AM
|
0
|
0
|
1479
|
|
POST
|
Good Afternoon all: I have a status update on this issue. On Friday, while working with Jon at ESRI Redlands, he was able to sucessfully re-create the behavior we have been experiencing regarding the bundle error move. In fact, Jon reported back to me that he saw the same behavior at 10.2.1 which I found quite interesting as we never experienced a bundle error move at 10.2.1, only cache failures for a given extent which could always be reparied. However, the good news is that this 10.2.2 bundle move error has now been logged as a NIM: [#NIM104348 In ArcGIS Server 10.2.2, you're unable to recache tiles while the existing tiles are being accessed. ] Which of course means the development team will now be looking at this issue. In the meantime, we all can go back to caching identical non-production services either on an edn or on a production GP cluster machine, as long as that service is not being accessed, and then moving the new bundles to production using REMDIR and XCOPY bat's. I have since last Thursday successfully completed three full UPDATE_EXISTING_TILES operations on a non-load basemap service of considerable cartographic complexity from scales of 577000k down to 1128K, both with and without the use of an AOI polygon. Thanks- David
... View more
08-18-2014
09:10 AM
|
5
|
2
|
1479
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 03-27-2026 01:27 PM | |
| 2 | 03-25-2026 06:29 AM | |
| 2 | 03-04-2026 11:14 AM | |
| 1 | 02-26-2026 09:46 AM | |
| 1 | 10-30-2025 11:25 AM |
| Online Status |
Offline
|
| Date Last Visited |
a week ago
|