Does not work if only geocoding City and State places

If there is not a value in Address 1 field the tool will not work. In the unmatched log it shows the addresses matched 100% but they are still not populated in the FC. If the same dataset is run with the same locator in ArcGIS Pro all locations appear in the FC.

Does anyone check these issue posts??

@jneedle79
Sorry for the delay. Yes the tool is designed to work with records that have street address information, not just City and State place information. I've looked into the tool a little further to see if we could get it to work with just City and State Information:

In my tests, I found like you that the tool would create an output log that shows a 100% match for addresses with City and State information only, however it was not adding the geocoded records to the output target feature class. If your process was similar to mine here is an example of record in the output log:

The key word above is the word "Locality", this is the addr_type of the geocoded record: https://developers.arcgis.com/rest/geocode/api-reference/geocoding-service-output.htm#GUID-D8DE94E9-5E2E-480D-9DE3-2212B9D7350D

The Import Records tool accepts the following addr_types for matches: "AddrPoint", "StreetAddr", "BldgName", "Place", "POI", "Intersection", "PointAddress", "StreetAddress", "SiteAddress","Address", "StreetAddressExt", "StreetInt". The tool was designed this way because it was meant to primarily deal with local address type records at parcels.

If you look at line 47 in the "import_records.py" python script that comes with tool you should see the following:

# Accepted levels of geolocation
addrOK = ["AddrPoint", "StreetAddr", "BldgName", "Place", "POI", "Intersection", "PointAddress", "StreetAddress", "SiteAddress","Address", "StreetAddressExt", "StreetInt"]

You can modify this line to allow it match other addr_types such as Locality by doing this:
# Accepted levels of geolocation
addrOK = ["AddrPoint", "StreetAddr", "BldgName", "Place", "POI", "Intersection", "PointAddress", "StreetAddress", "SiteAddress","Address", "StreetAddressExt", "StreetInt", "Locality"]

You may need to add other addr_type aside from "Locality" to the list above to bring in all the records you are trying to import.
After I made this change and saved the import_records.py file, I was able to successfully add "City, State" addresses to my target features when running the Import Records tool.
Hope this helps!

Thanks for your help, that worked!!
Jake Needle, GISP
GIS Program Manager
Woodard & Curran
980 Washington Street, Suite 325N
Dedham, Massachusetts 02026
p:<PHONE_NUMBER> x2546 | p:<PHONE_NUMBER> (Direct)
e: jneedle<EMAIL_ADDRESS>From: Ryan Cosby<EMAIL_ADDRESS>Sent: Monday, June 8, 2020 11:45 AM
To: Esri/incident-import-tools<EMAIL_ADDRESS>Cc: Jake Needle<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Esri/incident-import-tools] Does not work if only geocoding City and State places (#17)
@jneedle79https://github.com/jneedle79
Sorry for the delay. Yes the tool is designed to work with records that have street address information, not just City and State place information. I've looked into the tool a little further to see if we could get it to work with just City and State Information:

In my tests, I found like you that the tool would create an output log that shows a 100% match for addresses with City and State information only, however it was not adding the geocoded records to the output target feature class. If your process was similar to mine here is an example of record in the output log:
[image]https://user-images.githubusercontent.com/11748268/84050227-4e135380-a962-11ea-993a-9c536db2cfa6.png
The key word above is the word "Locality", this is the addr_type of the geocoded record: https://developers.arcgis.com/rest/geocode/api-reference/geocoding-service-output.htm#GUID-D8DE94E9-5E2E-480D-9DE3-2212B9D7350D
The Import Records tool accepts the following addr_types for matches: "AddrPoint", "StreetAddr", "BldgName", "Place", "POI", "Intersection", "PointAddress", "StreetAddress", "SiteAddress","Address", "StreetAddressExt", "StreetInt". The tool was designed this way because it was meant to primarily deal with local address type records at parcels.
If you look at line 47 in the "import_records.py" python script that comes with tool you should see the following:

Accepted levels of geolocation
addrOK = ["AddrPoint", "StreetAddr", "BldgName", "Place", "POI", "Intersection", "PointAddress", "StreetAddress", "SiteAddress","Address", "StreetAddressExt", "StreetInt"]
You can modify this line to allow it match other addr_types such as Locality by doing this:
Accepted levels of geolocation
addrOK = ["AddrPoint", "StreetAddr", "BldgName", "Place", "POI", "Intersection", "PointAddress", "StreetAddress", "SiteAddress","Address", "StreetAddressExt", "StreetInt", "Locality"]
You may need to add other addr_type aside from "Locality" to the list above to bring in all the records you are trying to import.
After I made this change and saved the import_records.py file, I was able to successfully add "City, State" addresses to my target features when running the Import Records tool.
Hope this helps!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/Esri/incident-import-tools/issues/17#issuecomment-640711077, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANULMZSTEMRYX6HJFYYXMGDRVUBQFANCNFSM4NE7ZMEQ.


LE Audio: Stop PA sync as Broadcast Sink but keep BIG sync

Is your enhancement proposal related to a problem? Please describe.
Currently the lifetime of a Broadcast Sink is heavily tied to the lifetime of the periodic advertising (PA) sync. Once a broadcast sink has synced to the BIG, it does not need to continue listening to the PA sync, and can actually terminate that.
Describe the solution you'd like
Remove the tight coupling between the PA sync and the Broadcast Sink, and add support for deleting the PA sync while still keeping the BIG sync. Only if both the PA sync and BIG sync are deleted, should the broadcast sink be delete.
Describe alternatives you've considered
N/A
Additional context
A broadcast source may never terminate the PA and keep the BIG as per the BAP spec.

Closing as duplicate of https://github.com/zephyrproject-rtos/zephyr/issues/52508

Closing as duplicate of https://github.com/zephyrproject-rtos/zephyr/issues/52508


[AutoPR] containerservice/resource-manager

Created to accumulate context: containerservice/resource-manager

(message created by the CI based on PR content)


Migrate to MavenCentral

JCenter will be soon shutdown, may you move this library to Maven Central?
Thank you

Just saw that there is a fork for that. Closing this now

Hey, which fork are you referring to?

https://github.com/firozanawar/Android-YouTube-Player

That's just an old version of the library. I suggest you follow issue #703

Have you seen this?

again, please look at issue #703

Yeah already read that, you mean are we going to wait till that date?

I mean there is not rush at the moment.

Ok ok thanks


Try some diagrams on docs

https://build-me-the-docs-please.readthedocs.io/en/latest/Using_Sphinx/UsingGraphicsAndDiagramsInSphinx.html

Seems too complicated:
WARNING: dot command 'dot' cannot be run (needed for graphviz output), check the graphviz_dot setting


Program page indicator search: Unexpected behavior when accessing search toward the bottom of the screen

I'm noticing some unexpected behavior with the indicator search bar. This is appearing on Production in addition to QA, so not a recent regression.
Looking at a program page on my laptop. When the search bar is toward the lower part of the screen, the search bar and type-ahead list jump up above the drop-down element, like so.

Next, when I type into the search box, there is suddenly a big gap between the search area and the drop-down element, like so:

What I would expect and prefer is that the search box and type-ahead results would stay docked below the drop-down, and if I want to see more of it, I need to scroll.

I am unable to reproduce this issue in Huckleberry, search bar behavior appears to be normal. moving to ready for deploy.

Deployment Verification

[x] Confirmed “Ready for Deploy” status
[x] Media Verified:


provide an error message when Profile or Entrypoint are not supported

libyami client should have a meaningful error message displayed when either the Profile or Entrypoint are not supported.  User should realize that the particular generation of hardware doesn't support a Profile or Entrypoint that is going to be used. .

In addition, perhaps yamiinfo should be capable of relaying this information, too?

This need run time driver caps check


Refactor features into sub-directives

As per my comment here: https://github.com/angular-ui/ui-select/pull/327#issuecomment-63140246
I think I would like to see all the features get split out into their own respective directives instead of cramming them all together in one giant one. This way (in the future) if you don't want a feature you can compile your codebase without it (in theory anyway). At the very least it would help make the testing and scope of each directive much easier to deal with and improve the overall API.
How would this work?
uiSelect.directive('uiSelect', function(){
  // doesn't contain multiselect or tagging functionality (theoretically)
});
uiSelect.directive('multiple', function(){
  return {
    restrict: 'A',
    require: [ 'multiple', '?uiSelect'], // making it optional in case some other directive uses a 'tagging' attribute
    controller: function() {
      return {...}; // shareable api goes here
    },
    link: function($scope, $element, $attrs, controllers) {
      var ctrl = controllers[0];
      var uiSelectCtrl = controllers[1];
      if (!uiSelectCtrl) return;
      // add multi-select features here
    }
  };
});
uiSelect.directive('tagging', function(){
  return {
    restrict: 'A',
    require: [ 'tagging', '?uiSelect', '?multiple'], // making it optional in case some other directive uses a 'tagging' attribute
    controller: function() {
      return {...}; // shareable api goes here
    },
    link: function($scope, $element, $attrs, controllers) {
      var ctrl = controllers[0];
      var uiSelectCtrl = controllers[1];
      if (!uiSelectCtrl || !multipleCtrl) return;

      // We can now use uiSelectCtrl to communicate and initialize
      $attrs.$observe('tagging', ...);
      $attrs.$observe('taggingTokens', ...);
      // etc, etc
    }
  };
});

Checking some old issues I just read this one and looks like we were thinking alike on this.
I already start splitting code on https://github.com/angular-ui/ui-select/pull/731


Upgrade to support mssql 4.2

Environment
Knex version: 0.15.2
Database + version: mssql 2016
OS: Mac OS X
Feature discussion / request

Explain what is your use case

Tedious has deprecation warnings in mssql 4.1.0 which is fixed in mssql 4.2.1

We have locked mssql version to current one because I had to monkeypatch some of its code to make driver to be more stable...
If it must be touched again it is easier to drop mssql driver and use tedious directly.

Where is the location of the monkeypatch code and would you be interested in someone making a fork and working on switching over to tedious?

I've been planning to do it at some point, but there are more important things to do for me before that. Monkey patch code is in mssql dialects code IIRC where driver in initialized.

@elhigu Could we maybe consider monkey patching 4.2 as well? Those tedious deprecated messages are super annoying... Not sold on why using tedious directly would be much better. The syntax is much simpler to use node-mssql as async/await abstraction layer on top of tedious.

@jerfowler Because generic-pool is buggy as hell. @elhigu already said he is not going to spend any additional effort on updating node-mssql support. Not sure if he would consider someone else's PR.

Not sold on why using tedious directly would be much better.

I have read and played with the code of node-mssql quite a lot when I was debugging knex's mssql stability issues.
I am very much convinced that using tedious directly is better choice for stability, getting new features faster, getting rid of extra dependency and well... node-mssql doesn't bring any benefits for knex over tedious. Only drawbacks.

The syntax is much simpler to use node-mssql as async/await abstraction layer on top of tedious.

This is not relevant for knex. Driver does only few calls to node-mssql query APIs and they are trivial to write with any flavor of async coding. Even if knex uses tedious directly, it doesn't prevent from using node-mssql in the same project separately if one likes.

@elhigu Thank you, very good points. However, wouldn't removing node-mssql be a breaking change? There could be numerous knex users that have a need to use the native Microsoft driver with node-mssql, perhaps for the Integrated Windows Authentication and Linked Servers which isn't quite supported by tedious yet. Both are very much valid use cases for utilizing the native driver and there could be others. Seems to me you are overlooking that population of knex users and forcing their hand by making that change.
Not to mention super confusing to have to npm i tedious for mssql when  npm i mssql is much more intutive. Why not add tedious as its own dialect and keep mssql as-is? After upgrading to 4.2.1 that is... ;-P
It's unfortunate that node-mssql hasn't accepted your pull request yet. However, Tedious doesn't seem to be much better in handling their pull requests, and both projects are being maintained by the same team.

@jerfowler there were some updates done in mssql driver and it seems to work ok for now, so there is no urgent plan to migrate out from it right now. But future shows where it leads...

However, wouldn't removing node-mssql be a breaking change? There could be numerous knex users that have a need to use the native Microsoft driver with node-mssql, perhaps for the Integrated Windows Authentication and Linked Servers which isn't quite supported by tedious yet.

There is not a single knex user in the world, who is using the native Microsoft driver with it. Internally knex always uses tedious with mssql driver (initializations that are hidden inside dialect code should be done in a different manner to be able to use it).

Not to mention super confusing to have to npm i tedious for mssql when npm i mssql is much more intutive.

Doesn't matter, its just about documentation and error messages to guide the user.

Why not add tedious as its own dialect and keep mssql as-is? After upgrading to 4.2.1 that is... ;-P

Because of pain of maintaining multiple dialects, specially when other is not stable/well maintained and other one is. It would be just confusing for the user... a bit like if I should use mysql or mysql2.

It's unfortunate that node-mssql hasn't accepted your pull request yet. However, Tedious doesn't seem to be much better in handling their pull requests, and both projects are being maintained by the same team.

This is not true. Mssql driver was moved under tedious/tedious team in github only recently, because there was no maintainer for it.  They mainly maintain, develop an update tedious and mssql is there just for future, if someone would like to start maintaining it. So it is not comparable situation.
@jaskle umm... ok please don't ignore them... I have no idea what do you mean by that comment. What does that have to do with this issue?


chore(deps): update dependency @typescript-eslint/parser to v5.45.0

This PR contains the following updates:

Package
Type
Update
Change

@typescript-eslint/parser
devDependencies
minor
5.44.0 -> 5.45.0

Release Notes

typescript-eslint/typescript-eslint
v5.45.0
Compare Source
Note: Version bump only for package @typescript-eslint/parser

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

⚠ Artifact update problem
Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.
♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:
File name: package-lock.json
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.24/images/create?fromImage=renovate%2Fsidecar&tag=latest: dial unix /var/run/docker.sock: connect: permission denied


/etc/hosts ignored

Looks like docker images based on prom/busybox like prom/alertmanager ignoring /etc/hosts entries
Could you guys add the following to the Dockerfile ? :
echo 'hosts: files dns' >> /etc/nsswitch.conf

Go DNS is just DNS, it doesn't use gethostbyname and thus Prometheus and Alertmanger do not use the contents of nsswitch.conf. Changing this file is probably not what you want.

CoreDNS has a /etc/hosts plugin. that can be used to solve this.

Go DNS does support nsswitch.conf and reading from /etc/hosts this way. The missing bit is the nsswitch.conf in the Dockerfile.  I'm not sure that's enough, as it would still need the hosts file mapped in as well.

Tested, and looks like it works with nsswitch.conf, docker uses the hots /etc/hosts file

That's new, when did this change?

Closing as #16


Could react-msaview highlight the node or branch using different colors?

Hello~
Thank you for developing this useful app. I have a question about the nodes with links of structuremodel being shown in blue. Is it possible for react-msaview to highlight specified nodes? If so, which parameters should I use?
Best regards,
DJ

currently the nodes in blue are ones that i have known PDB ID's for, it's a bit hardcoded, but I would like to add a more general coloring scheme though, there was the idea of using the 'lineageColors' concept from UCSC possibly here https://github.com/GMOD/react-msaview/issues/5
I am currently picking up work on this project again so I may be able to address this soon

Thanks for your reply~ Looking forward to the update of this function.


1.13.1 -> 1.13.2 removes comments from schema

Describe the bug
Comments from the schema are gone in the generated code.
To Reproduce
Steps to reproduce the behavior:

My GraphQL schema:

type Query {
  # A name!
  name: String!
}

My GraphQL operations:

# none

My codegen.yml config file:

generates:
  ./gqltypes.ts:
    schema: ./schema.graphql
    plugins:
      - 'typescript'

Expected behavior
1.13.1 generates comments
export type Maybe<T> = T | null;
/** All built-in and custom scalars, mapped to their actual values */
export type Scalars = {
  ID: string;
  String: string;
  Boolean: boolean;
  Int: number;
  Float: number;
};

export type Query = {
   __typename?: 'Query';
  /** A name! */
  name: Scalars['String'];
};

1.13.2 does not
diff --git i/gqltypes.ts w/gqltypes.ts
index 41d3dfebf..3172daf0e 100644
--- i/gqltypes.ts
+++ w/gqltypes.ts
@@ -10,6 +10,5 @@ export type Scalars = {

 export type Query = {
    __typename?: 'Query';
-  /** A name! */
   name: Scalars['String'];
 };

Environment:

OS: macOS
@graphql-codegen/...:  1.13.2
NodeJS: 12.16.1

Additional context

Could you add commentDescriptions option like below and try again?
generates:
  ./gqltypes.ts:
    schema:
        - ./schema.graphql:
              commentDescriptions: true
    plugins:
      - 'typescript'

That makes no difference

In GraphQL Spec, comments with # are deprecated so you need to use """ descriptions instead.
You can see here;
https://github.com/graphql/graphql-js/pull/927
Not sure if we change the behavior because supporting both descriptions and comments might break things. @dotansimha
Maybe the following would work;
generates:
  ./gqltypes.ts:
    schema: ./schema.graphql:
    plugins:
      - 'typescript'
    config:
       commentDescriptions: true

Aha, I didn't know that, thanks for the link! I'd still consider it worth pointing out in the changelog though. The only close to it is

Fix issues with missing descriptions and comments when schema is loaded from a url source (#3804 )

We've migrated to using """ now, so this is solved for us. But again, it should be noted in the changelog and not silently dropped


header checkbox template and row checkbox template

Hi, I have added a little feature which I required for my project,
template for the checkbox in header and row, so that I can use material checkbox design,
thank you,
Riaz

Great PR, hopefully, the conflicts can be resolved so the PR can be merged, ATM it's very hard to style the checkboxes e.q. implement Bootstrap 4 custom checkbox design because the checkboxes don't have any wrapper nor label, only single input.

I didn't noticed the conflicts until i saw ur message, thanks

the following is always returning true in table header even when there is no slot provided.
hasCheckboxTemplate() {
      return !!this.$slots['table-checkbox-column']
        || !!this.$scopedSlots['table-checkbox-column'];
    },

Any movement on this PR? I'd like to use my own checkbox component in order to match the rest of my design but cannot without a slot.


2.2.5 Counting Sort & Radix Sort

Description
Give an introduction and explain the working of Counting Sort and its complexity, Radix sort and its usage and complexity and how it uses counting sort as a subroutine to sort, and its applications
Task

[ ] Documentation
[ ] Audio
[ ] Video

Note

While requesting the issue to be assigned, please mention your NAME & BATCH NUMBER.
Kindly refer to Issue Guidelines.
In case you see that the issue has already been assigned, try to request for a different task within the same issue.
Changes should be made inside the DSA/directory & DSA branch.
Name of the file should be same as the issue.
This issue is only for 'GWOC' contributors of 'DSA' Domain.

/assign
Shivani Paliwal
dsa-batch-4

/assign

@ShivaniPaliwal29  have made your contribution to this issue?


get_language_links uses deprecated parameter llurl

>>> import wapiti
>>> client = wapiti.WapitiClient('')
>>> client.get_language_links('house')
may have an error: [u'main: Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes. Use [[Special:ApiFeatureUsage]] to see usage of deprecated features by your application.', u'langlinks: The parameter "llurl" has been deprecated.'] ('http://en.wikipedia.org/w/api.php?titles=house&llurl=True&format=json&action=query&servedby=true&lllimit=500&prop=langlinks')

@ygreif thanks for the report! Kind of a blast from the past. No promises on when/whether I'll get to this, but I can reproduce the issue, so I'll leave it here as a great start toward a contribution :)