Why does 'around' work but 'area' doesn't in Overpass Turbo? - geolocation
I have the following overpass turbo query:
[out:json];
area[name="Zagreb"];
(
node["tourism"~"museum|gallery"](area);
node["amenity"~"cafe|bar"](area);
);
out center;
You can run it here: https://overpass-turbo.eu/s/1hmp
The problem is that it only returns the first node, so the tourism="museum|gallery" in this case, but not the amenity="cafe|bar".
I based my query on this answer, where both nodes get returned(!!!): Find multiple tags around coordinates with Overpass API
[out:json];
(
node["tourism"~"museum|gallery"](around:500,53.866444, 10.684738);
node["amenity"~"cafe|bar"](around:500,53.866444, 10.684738);
);
out center;
You can run this original one here: https://overpass-turbo.eu/s/1hml
Except that I changed the 'around' to the area of name="Zagreb". And this clearly works (although just for one of the nodes).
Does anyone have any ideas how to get both nodes (tourism="museum|gallery" and amenity="cafe|bar") to work within an area?
Thanks so much!
Lovro
You need to store the area in a named inputset (below it's named ".myarea"), otherwise the result of the first node statement would overwrite the area in the default inputset (called ._), and would no longer be available for the second node query.
[out:json];
area[name="Zagreb"]->.myarea;
(
node["tourism"~"museum|gallery"](area.myarea);
node["amenity"~"cafe|bar"](area.myarea);
);
out center;
Quite a frequent issue by the way, and I'm sure there are several other post that already deal with this error.
Related
Vaadin 14 FlagItems not aligned correctly on ListSeries
I've got a problem regarding the FlagItem in Vaadin 14.
I'm trying to set a FlagItem for a specific point in a ListSeries, I'm doing this the following way:
PlotOptionsFlags plotOptionsFlags = new PlotOptionsFlags();
plotOptionsFlags.setOnSeries(wageEntry.getEmployeeCode());
plotOptionsFlags.setShape(FlagShape.SQUAREPIN);
plotOptionsFlags.getTooltip().setPointFormat("Wage: {point.y}");
plotOptionsFlags.getTooltip().setHeaderFormat("");
plotOptionsFlags.setShowInLegend(false);
DataSeries flagsSeries = new DataSeries();
flagsSeries.setName(wageEntry.getEmployeeCode().concat(" Current Wage"));
flagsSeries.setPlotOptions(plotOptionsFlags);
for (WageEntry wage : employeeWageEntries) {
if (wage.getWageYear() == LocalDate.now().getYear()) {
flagsSeries.add(new FlagItem(wage.getAge() - 22, wage.getEmployeeCode().concat(" - ").concat(String.valueOf(wage.getWageAmount()))));
}
}
comparisonChartConfiguration.addSeries(flagsSeries);
As you can see, I set the x value relative to the age of an entry, and the text. More over the FlagItem is only created when a certain condition is met. (I used the Vaadin Chart Demo as reference: https://demo.vaadin.com/charts/Flags)
The problem now is, that when the chart is being built, the FlagItem appear on the x axis instead as you can see here:
I really don't understand why this happens.
Maybe it's useful to know, that on the chart three RangeSeries and multiple ListSeries are being drawn.
Thanks for the help!
So I've found out where the problem was. It was something that wasn't added to the code above, so please have mercy. The issues lied withing the fact that I didn't add the ListSeries to the comparisonChartConfiguration before creating the flagsSeries. In short, you need to add the Series you want to append flags on to the ChartConfiguration before you can attach the flagsSeries onto another.
Acumatica Customization: Add PO Nbr column to SO Line
I am trying to create a customization to add the PO Nbr associated in the PO Link graph to a column in the SO Line. I know the link is made in the SOLineSplit table, but I am struggling with how to actually show that field in the SO Line. I have made a custom Usr field for PO Nbr, but not sure what I should be entering in the attributes (or DAC extension, whatever is the best way) in order to show the PO Nbr data from the SOLineSplit table.
I remember struggling with this early on, so it's an excellent question. The challenge is that you mention getting to the PO from the SO LINE, but an SO Line can be split across multiple PO's. That's why you end up having to dig into the SOLineSplit for the link. Let's take a look at the link from SOLineSplit to PO...
There are a couple of possibilities when you look into the SOOrderEntry graph. The following code snippets show relationships. Your SOLineSplit may have a direct reference to the PO/POLine as shown here:
PXSelectBase<POLine> selectlinkedDropShips = new PXSelectJoin<POLine,
InnerJoin<SOLineSplit, On<SOLineSplit.pOType, Equal<POLine.orderType>,
And<SOLineSplit.pONbr, Equal<POLine.orderNbr>,
And<SOLineSplit.pOLineNbr, Equal<POLine.lineNbr>>>>>,
Where<SOLineSplit.orderType, Equal<Current<SOOrder.orderType>>,
And<SOLineSplit.orderNbr, Equal<Current<SOOrder.orderNbr>>,
And<POLine.orderType, Equal<POOrderType.dropShip>>>>>(this);
If that simple path doesn't get you there, the more detailed path of an SO to a PO lies in the INItemPlan reflecting the demand of the SOLineSplit (via the PlanID) and then tied to POLine via POLine.PlanID = INItemPlan.SupplyPlanID as shown in the following snippet.
foreach (PXResult<POLine, POOrder, INItemPlan, SOLineSplit> res in PXSelectJoin<POLine,
InnerJoin<POOrder, On<POLine.FK.Order>,
InnerJoin<INItemPlan, On<INItemPlan.supplyPlanID, Equal<POLine.planID>>,
InnerJoin<SOLineSplit, On<SOLineSplit.planID, Equal<INItemPlan.planID>,
And<SOLineSplit.pOType, Equal<POLine.orderType>,
And<SOLineSplit.pONbr, Equal<POLine.orderNbr>,
And<SOLineSplit.pOLineNbr, Equal<POLine.lineNbr>>>>>>>>,
Where<POLine.orderType, Equal<Required<POLine.orderType>>,
And<POLine.orderNbr, Equal<Required<POLine.orderNbr>>,
And2<Where<POLine.cancelled, Equal<boolTrue>,
Or<POLine.completed, Equal<boolTrue>>>,
And2<Where<POOrder.orderType, NotEqual<POOrderType.dropShip>,
Or<POOrder.isLegacyDropShip, Equal<True>>>,
And<SOLineSplit.receivedQty, Less<SOLineSplit.qty>,
And<SOLineSplit.pOCancelled, NotEqual<boolTrue>,
And<SOLineSplit.completed, NotEqual<boolTrue>>>>>>>>>
.Select(graph, poOrder.OrderType, poOrder.OrderNbr))
{...
As you can imagine, you would have to set some rules around restricting an SO Line to a single PO, but that honestly would be more trouble than it's worth as the standard functionality is valuable in being more robust. I would suggest either putting your link in the Allocations list (or Line Details in more recent versions of Acumatica ERP) or produce a smart panel popup to show all the PO links per splits of the current SO Line.
Cytoscape layout to use node attributes as coordinates?
Is there a way to use x,y coordinates stored as attributes of each node to layout a graph using the coordinates that were calculated by another program? And if not, would it be possible to implement this somehow - how does one get started on this? Is there a standard way how to provide the node positions to the cytoscape.js web viewer somehow? Background: it is trivial to use Python networkx to calculate some layouts which are not supported in Cytoscape, and it would also be trivial to store the coordinates as node attributes. All that would then be need is some way for Cytoscape to use those coordinates to find node positions instead of using a layout algorithm.
This is a quite easy thing to do. Many examples on use this functionlity in the demos, as you can see here:
1: FCose Demo
2: Cose Blicent Demo
3: d3-force Demo
4: Euler Compound Demo
5: Spread Demo
As you can see, there are an abundance of examples for this in the demos, but also in the docs. You can see one here and here:
// can use reference to eles later
var eles = cy.add([
{ group: 'nodes', data: { id: 'n0' }, position: { x: 100, y: 100 } },
{ group: 'nodes', data: { id: 'n1' }, position: { x: 200, y: 200 } },
{ group: 'edges', data: { id: 'e0', source: 'n0', target: 'n1' } }
]);
The json used in the .add() function can be created in your js application or directly in Python and added to the graph as some of the examples do.
In general, you should take some time and skim through through the docs. The ability to position nodes via x and y is quite basic and is one of the first pages in the docs.
If you don't understand the description in the docs and the examples I provided, please edit your question and add your current code as a Minimal, Reproducible Example, where you can show your efforts to implement the positioning.
Edit:
As #maxkfranz pointed out, the preset layout plays a big role here. The documentation states this in the Initialisation Chapter:
If you want to specify your node positions yourself in your elements JSON, you can use the preset layout — by default it does not set any positions, leaving your nodes in their current positions (i.e. specified in options.elements at initialisation time).`
I am new to using Cytoscape so things that are "easy" are not so easy for me. I often don't even know the right way to ask a question. Everyone has things that are hard and things that are easy, and step by step we expand our knowledge so what is hard today may be easy tomorrow. Anyway, here is something that may be a part of the solution you are looking for: In the Cytoscape desktop application, you can create a "Style" that maps a node attribute to "X Location" and another node attribute to "Y Location".
"EntityNotFoundException: Unable to load RELATIONSHIP with id" when saving RelationshipEntity (with huge generated cypher query)
I am using spring-data-neo4j 4.2.0.M1 and neo4j-ogm 2.0.4 with neo4j 3.1.0-M04.
The application is generally working, except for one case where I try to save a collection of modified RelationshipEntities.
The code is sth. like this:
List<Relationship> updatedRelationships = new ArrayList<>();
for(Relationship relationship : modifiedRelationships)
{
relationship = relationshipRepository.load(relationship);
relationship.setValue("value");
updatedRelationships.add(relationship);
}
relationshipRepository.save(relationships);
The RelationshipEntity is annotated with #RelationshipEntity and has a few properties in addition to the #StartNode and #EndNode. Only the property mentioned above is changed though. The RelationshipEntity is loaded inside the loop because I previously noticed lost information (namely value of other properties) when executing this.
Note that the above mentioned code is executes for many RelationshipEntities in succession. Each relationship (probably) occurs only once, but start and end nodes probably occur several times. To my knowledge, no relationship is deleted though.
The exception I get is:
Caused by: org.neo4j.kernel.api.exceptions.EntityNotFoundException: Unable to load RELATIONSHIP with id 20683203.
at org.neo4j.kernel.impl.api.store.DiskLayer.relationshipVisit(DiskLayer.java:432)
at org.neo4j.kernel.impl.api.store.CacheLayer.relationshipVisit(CacheLayer.java:326)
at org.neo4j.kernel.impl.api.StateHandlingStatementOperations.relationshipVisit(StateHandlingStatementOperations.java:1409)
at org.neo4j.kernel.impl.api.ConstraintEnforcingEntityOperations.relationshipVisit(ConstraintEnforcingEntityOperations.java:416)
at org.neo4j.kernel.impl.api.OperationsFacade.relationshipVisit(OperationsFacade.java:493)
at org.neo4j.kernel.impl.factory.GraphDatabaseFacade.getRelationshipById(GraphDatabaseFacade.java:300)
... 104 common frames omitted
The query that is executed before (which is probably the "save" query) is huge and exceed the character limit here (sth. like 200k characters). Apparently the query touches where more relationships than necessary (from business logic point-of-view) since only about 30 entities are actually saved. I would assume that the resulting query (or queries if updates are done per entity) are rather brief.
2016-08-28 20:16:33,007 I [pool-4-thread-1 ] (EmbeddedRequest.java:155) Request: START r=rel({relIds}) FOREACH (row in filter(row in {rows} where row.relId = id(r)) | SET r += row.props) RETURN ID(r) as ref, ID(r) as id, {type} as type with params {relIds=[13744338, 19099951, 12570789, 12570785, 13744377, 13648126, 12570765, 20627727, 13744356, 20627724, 12570760, 19263773, 19257628, 20113678, 19099932, 19259756, 18796874, 13783174, 19097972, 19083644, 19099970, 19097921, 19077446, 19263810, 13744312, 20568405, 20904270, 19097937, 12570827, 20627779, 20648258, 12570816, 20683195, 19259812, 20683194, 20683193, 20683192, 19083690, 20683186, 20683191, 19259819, 18819471, 20683178, 20683177, 12570669, 20683176, 19276210, 19933607, 20683171, 18844038, 19100089, 20683174, 20683173, 20683163, 20683162, 20683161, 13744242, 19257729, 12570649, 20683165, 20683164, 19087754, 21703141, 12570641, 8341711, 19259796, 8704051, 19915155, 19261851, 13783062, 13783063, 19091955, 18182597, 19276276, 19276275, 20623852, 20607468, 20623853, 19100155, 19233277, 13783048, 19261946, 12570719, 21789101, 12570718, 19075526, 19259842, 19257807, 12570707, 13715516, 19098061, 19261908, 20683208, 20683215, 19100118, 20683212, 20683203, 19276254, 20683201, 20683207, 19091934, 20683206, 19261915, 19097639, 19101736, 19101749, 18821129, 19097659, 19124284, 13662709, 13744628, 19052549, 19089427, 13744612, 19265563, 19251300, 19089509, 19251298, 20631665, 19251305, 19265642, 13744513, 19261558, 19261511, 19265606, 19081291, 18903113, 18903114, 19251273, 8341775, 12597685, 13744548, 19081308, 18725021, 18725020, 19273892, 19099808, 19089572, 19097772, 13744449, 13683011, 18178177, 19273905, 19093694, 18178231, 19124358, 20633756, 13744502, 19081356, 18651311, 19093661, 20562171, 19263725, 20625639, 19099901, 20631774, 20676819, 18651383, 20676822, 20676821, 20676820, 19097811, 19099862, 13744428, 20631751, 18178280, 18668312, 19100453, 19088171, 20708148, 19143487, 19088184, 19094334, 18668349, 13744883, 19145485, 20607750, 19094301, 19086108, 13744792, 20611958, 19143528, 13662849, 13744829, 12571346, 20611918, 20611919, 18811753, 19100506, 13744813, 19084195, 13662806, 20708275, 19098546, 20612001, 13744752, 20708253, 12595823, 20611976, 19147673, 19258343, 19274725, 19084262, 19082212, 19096548, 20591606, 19086317, 13662720, 8348332, 19274738, 8348329, 19096571, 21703569, 19440630, 13744654, 21824427, 13744701, 19258320, 20612032, 19086296, 19080158, 19282466, 19145249, 19261996, 20607539, 12596170, 19282472, 18776588, 19100208, 12596183, 18182658, 19233341, 19278395, 19096126, 19098115, 20640284, 18844217, 19255810, 19259919, 19257864, 20623892, 19091980, 19933697, 19282450, 19100180, 19261981, 12596219, 12596113, 19255924, 20707949, 12596118, 19098228, 18704970, 12596122, 19278458, 19096190, 19278456, 19253826, 19278412, 13745087, 19100241, 13745066, 18704995, 19278500, 13744981, 5954519, 19094199, 19143356, 13744970, 12598116, 18840242, 13745006, 18676445, 18008789, 19096298, 18676426, 20607724, 13744906, 13755199, 19094227, 12596419, 19098918, 19256621, 19090736, 21075287, 19100929, 21851496, 20876568, 13681912, 12596463, 12596465, 19090704, 10951825, 12596471, 13681897, 13753581, 19094814, 12596352, 21703948, 21695756, 18699605, 19256693, 18818378, 12596376, 19090755, 19256647, 13681844, 19082583, 18836839, 18699621, 12596409, 20618681, 21544395, 19916202, 12596299, 12596310, 19436940, 19099014, 19094918, 19916170, 13681782, 12596335, 20680073, 13681762, 13681763, 19099028, 19094938, 21081473, 13681682, 20680177, 12596242, 19099126, 19500540, 21081496, 10492993, 19099087, 21081517, 19099094, 21704112, 19098665, 18680849, 12596685, 12596689, 19274804, 20648995, 19137597, 21048411, 19088387, 19262470, 20657183, 19086357, 19258397, 18680869, 12596731, 19088413, 19272807, 19274848, 19272811, 12596622, 18811984, 15797667, 19096694, 19082357, 19262579, 19274875, 19137604, 12596642, 19274830, 19098696, 13682107, 12596651, 19096655, 20632650, 19088474, 19274845, 19262555, 19100834, 13682007, 19098794, 19100851, 12596565, 20556972, 19254450, 20597926, 12598622, 20597925, 20649114, 19100800, 13682036, 19100806, 12596582, 18703539, 20638856, 20598010, 18703582, 19094763, 19100905, 19096808, 20634857, 20597991, 5877179, 5877178, 20597977, 5877181, 19098822, 12596527, 12596532, 19199781, 19265313, 19261228, 20625200, 19257134, 20625201, 18714376, 19085108, 19253054, 19253048, 19265339, 20637459, 20637456, 19085074, 21081974, 8316482, 20598534, 18714402, 19107685, 19253090, 20615029, 19097462, 19263346, 20621152, 19263352, 19259207, 13729470, 19085140, 20688830, 19251116, 19259304, 13678173, 20615087, 12596830, 19097474, 21082087, 12596840, 19263368, 19251093, 8701488, 19267475, 8349384, 12572165, 8349360, 12596751, 19077119, 12596765, 20625380, 19077057, 19089350, 21825447, 21702567, 13682208, 12596785, 8316559, 18178020, 19253207, 20688847, 12596788, 19267536, 20688838, 12570558, 19232295, 12570550, 13783001, 20643352, 20694547, 19095051, 20643338, 19232272, 12570505, 20641280, 20694529, 20641284, 19099164, 20821624, 20821626, 20631165, 20821619, 12570606, 19439229, 12570601, 18820674, 19232327, 12570588, 20694621, 20641362, 20119134, 20631115, 20680264, 20618831, 19093080, 18824862, 19256994, 7325670, 20821668, 19257017, 13782863, 16494427, 20620952, 19256967, 20637331, 18030271, 8267731, 19256977, 20670095, 19099360, 20637433, 19261170, 19265276, 20907749, 18822910, 20621021, 19099339, 19252938, 19936961, 19099345, 19109599, 19257048], rows=[omitted]
I've tried to load the relationship with that id directly, but none exists. The same code executes fine for other RelationshipEntities but repeatedly fails for either this or one of a handful other ones.
Any ideas as to what could cause this or how this can be better debugged?
I think I somehow solved this with the following steps: Replaced saving the RelationshipEntity with saving the modified NodeEntity Making such modifying operations sequential (previously this could happen in parallel) Encapsulate the modifying operation in a transaction Fixed a bug where in the same transaction the same entity was saved twice (without changing again in the meantime) Fetching the entity again at the beginning of the transaction in order to have the latest state available Since I was prettty much in the dark about this topic until it finally worked, I am not sure if all of the steps actually helped solving this. It may actually have been only a subset. What I can see though now is, that the huge update queries are now smaller (albeit still quite big) but actually seem to contain "real" updates instead of mostly "null" properties. I assume that previously it didn't really contain an update and was instead overriding properties with "null". The fact that this is now working is probably related to the fact, that the entity is now updated before beginning to modify it and that no other modifying operation can run in parallel.
I had the same problem. For me it was simply the neo4j-ogm-embedded-driver version I had to include in my pom. The one I defined overwrote the one defined in spring-data-neo4j.
If you only save the relationshipEntity,you could only using next snippet:
List<Relationship> updatedRelationships = new ArrayList<>();
for(Relationship relationship : modifiedRelationships)
{
relationship = relationshipRepository.load(relationship);
relationship.setValue("value");
updatedRelationships.add(relationship);
}
relationshipRepository.save(updatedRelationships,0);
it would save the related properties on relationshipEntity and meanwhile ignore any related entities.
apply new layer to a slice of a volume webgl
i have two volumes (.nrrd) of different qualities. the user can browse through the layers. if a key is pressed
i want to load the slice of the volume with better quality.
my volume is similar to this one: lesson 10 xtk
i've found:
volume.children[2].children[0].children[0].texture.file = "http://path/to/file.ext";
but if i apply some kind of file (.jpg, .dcm) nothing happens.
is this the right approach to change the slice to go inside the children and change the texture?
or shall i load the selected slice seperate as an object and apply it to the "lower-quality-volume" somehow?
edit:
this is what i tried so far (i get errors with dcms but not with jpgs):
if (event.keyCode == 83) { // "s"-button
volume.children[2].children[0].children[0].texture.file = "http://localhost:3000/112.jpg";
volume.children[2].children[0].children[0].modified();
r.render();
}
edit2: this is whats in my r.onShowtime = function() {}
volume.children[2].children[0].texture.file = 'http://localhost:3000/112.jpg';
volume.children[2].children[0].visible = true; // to activate the first layer
volume.children[2].children[0].modified();
console.log(volume.children[2].children[0].visible +" "+ volume.children[2].children[0].texture.file);
it outputs "true hostname/112.jpg"
when i inspect the .jpg in firebug the header is ok but the answer is "null"
when i inspect console.log(volume.children[2].children[0]); with firebug
.texture.file is set to hostname/112.jpg
when i go to "network" the .jpg has been transfered successfully
please notice that 112.jpg and level.jpg are the same. the first one is getting loaded in r.onShowtime and the other one is loaded at a keypressed event.
EDIT 3: volume.children[2].children[0] is of the type "X.slice", isn't it?
here is my approach: jsFiddle
and this is my actual issue and still not working: jsFiddle
Mhh..
I think a call to object.modified() is missing in the file setter (and in others setters from inject classes). Let's see when Haehn will come if he wants to change something internaly, but for the moment could you try to call it by yourself ?
You can try to add after the modification of texture :
volume.children[2].children[0].children[0].modified();
And if it doesn't work, in addition :
renderer.render();
Edit :
It's strange, I did a similar code and it did something. Can you please try something like that with opening your javascript console (Firefox, Chrome,... has one) and tell me the error you get ?
renderer.onShowtime = {
for (var i=0 ; i< volume.children[2].children.length ; i++) {
volume.children[2].children[i].texture.file="myimage.jpeg";
volume.children[2].children[i].modified();
}
}
It is important you call it in the onShowtime, because before the volume is not loaded, and so slicesX, slicesY... don't exist.
Edit2 :
Hey,
Thanks to the informations you added I think I've got the point ! In the render() method of our renderer3D there is a test on texture._dirty flag, that you cannot change from outside the framework. In addition the 1st rendering with a texture make that flag false, and loading a new texture doesn't seem to set that flag back to true in the current XTK. So, I think, we have to add it in the loader.load(texture, object) method. I'll make an issue on Github and see what Haehn thinks of it !